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'End  user  computing  has  penetrated  most  large  organiza¬ 
tions  in  an  uncontrolled  fashion.  The  newness  of  the  tech¬ 
nology,  the  lack  of  management  expertise,  and  the  inability 
to  gain  corporatewide  control  under  the  traditional  organi¬ 
zational  structure  have  often  resulted  in  inefficiency, 
incompatibility,  and  missed  opportunities.  One  solution  to 
this  situation  is  the  Information  Center  (IC).  ICs  are 
centralized  coordination  centers  for  end  user  computing  and 
offer  end  user  computing  expertise.  ICs  may  be  any  combina¬ 
tion  of  consulting  services,  training  services,  mainframe 
computer  terminals,  or  microcomputers.  This  thesis  examines 
the  IC  concept  from  the  viewpoint  of  the  manager  tasked  with 
implementation  and  provides  a  methodology,  the  Systems 
Development  Life  Cycle,  to  evaluate  and  implement  an  IC. 

Each  phase  of  the  methodology  is  explained  and  some  innova¬ 
tive  ideas  on  IC  implementation  and  operation  are  provided. 

Examples  of  past  successes  and  mistakes  are  also  presented. 
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INTRODUCTION 


I . 

A,  INFORMATION  CENTER  DEFINED 

The  concept  of  the  Information  Center  (IC)  was  formal¬ 
ized  by  International  Business  Machines  (IBM)  Canada  in  1974 
[Ref.  1:  p.  73].  IBM  defines  the  IC  as  "a  portion  of  the 
Information  Systems  development  resource  organized  and  dedi¬ 
cated  to  support  the  users  of  Information  Systems  services 
in  activities  such  as  report  generation  and  modification, 
data  manipulation  and  analysis,  spontaneous  inquiries,  etc." 
[Ref.  2:  p.  131]  Other  corporations  have  used,  changed, 
renamed,  refined,  and  redefined  the  IC  concept  to  fit  their 
own  purposes.  Although  this  flexibility  may  appear  to  be 
counterproductive,  it  seems  to  be  one  reason  for  the  popu¬ 
larity  of  ICs . 

Many  corporations  have  adopted  the  name  Information 
Center.  Some  of  the  other  documented  names  for  ICs  include 
Information  Resource  Center  [Ref.  3;  p.  27],  Client  Support 
Center  [Ref.  4:  p.  137],  User  Support  Group  [Ref.  5;  p.  16], 
Resource  Center  [Ref.  6;  p.  19],  User  Development  Applica¬ 
tion  Center  [Ref.  7:  p.  65],  Solution  Center  [Ref.  8: 
p.  30],  and  Office  Technology  Center  [Ref.  9:  p.  71]. 

The  term  Information  Center  has  also  been  used  to  desig¬ 
nate  other  manual  or  automated  services  such  as  library 
services,  abstract  and  document  retrieval  services,  and 
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central  repositories  for  documents.  Although  valid,  these 
services  represent  an  entirely  different  concept  and  are  not 
a  consideration  of  this  research. 

The  IBM  definition  of  the  IC  focuses  on  the  use  of  a 

mainframe  computer.  This  narrow  focus  does  not  adequately 

define  the  IC  concept  used  by  many  corporations.  Therefore, 

the  following  three  definitions  are  provided: 

The  Information  Center  is  not  a  place;  it  is  a  concept 
which  combines  technology  and  the  technical  expertise  of 
the  MIS  department  of  the  organization  with  the  business 
skills  of  those  in  other  areas  in  the  organization  to 
better  leverage  both  the  power  of  information  processing 
technology  and  the  organization's  data.  [Ref.  10:  p.  42] 

. . .an  IC  is  an  organization  whose  objective  is  to  provide 
the  tools  and  support  that  allow  end  users  to  deal  direct¬ 
ly  with  some  subset  of  their  MIS  needs.  As  such,  the  IC 
facilitates  end-user  computing,  providing  tools  rather 
than  solutions.  [Ref.  11:  p.  16] 

An  information  center  consists  of  a  facility  and  resources 
which  can  allow  users  to  carry  out  their  own  data  process¬ 
ing  according  to  their  immediate  needs.  [Ref.  12:  p.  63] 


B.  PURPOSE 

The  purpose  of  this  research  is  to  develop  a  method  or 
guide  for  managers  to  evaluate  and  implement  the  IC  concept. 
Therefore,  the  perspective  of  this  thesis  is  from  that  of 
the  manager  tasked  with  the  responsibility  for  evaluation 
and  implementation  of  the  IC.  This  person  is  often  from  the 
data  processing  or  management  information  systems  depart¬ 
ment.  The  methodology  used  is  the  systems  development  life 
cycle  (SDLC).  Selection  of  this  method  was  based  on  the 
idea  that  an  IC  can  be  thought  of  as  a  large  project  or 


system.  Managers  need  a  framework  within  which  they  can 
develop  the  IC  concept  and  SDLC  provides  one  of  the  sim¬ 
plest,  most  complete,  and  adaptable  methods  available. 
Recently,  SDLC  has  gained  great  popularity  within  the  infor¬ 
mation  industry  in  the  design  of  computer  information  sys¬ 
tems.  Another  reason  to  use  SDLC  is  that  managers  who  used 
SDLC  before  will  be  able  to  more  easily  evaluate  and  imple¬ 
ment  ICs. 

C.  DESCRIPTION 

Descriptions  of  ICs  are  varied  and  plentiful.  One  at- 
tem.pt  to  provide  a  standard  description  of  ICs  is  the 
following : 

The  centers  (ICs)  may  differ  in  the  services  and  facili¬ 
ties  they  offer... But  information  centers  all  have  the 
fast,  convenient  characteristics  of  the  hot  line,  and  they 
all  endeavor  to  empower  users.  [Ref.  13:  p.  98] 

ICs  are  more  commonly  found  in  large  corporations,  but 
are  rapidly  migrating  to  smaller  ones  as  the  popularity  of 
the  IC  concept  increases.  Most  IC  implementations  include  a 
physical  facility  with  a  manager,  an  administrative  assist¬ 
ant  or  secretary,  and  one  or  more  people  designated  to 
conduct  training  and  consultation.  Although  other  positions 
and  functions  can  be  found  in  the  various  ICs,  this  descrip¬ 
tion  IS  fairly  generic.  The  physical  layout  usually  in¬ 
cludes  some  sort  of  terminal  or  mix  of  terminals.  The 
quantity  and  arrangement  of  terminals  will  depend  on  the 
purpose  of  the  facility.  In  physical  terms,  the  IC  may  be 

1  1 


however,  retain  a  basic  sequential  flow  from  the  point  of 
origin  of  the  development  cycle--"new  problems  and/ or 
opportunities  arise . "  At  any  step  in  the  cycle,  previ¬ 
ously  unidentified  problems  and/or  opportunities  may  be 
discovered.  In  such  cases,  it  is  important  to  insure 
proper  integration  of  a  solution  to  a  new  problem  and/or  a 
new  opportunity.  Making  even  a  minor  change  to  a  system 
without  proper  consideration  of  what  has  been  established 
previously,  can  cause  unanticipated  and  undesirable  rip¬ 
pling  effects.  [Ref.  25:  p.  11] 


E.  GENERAL  COMMENTS 

Some  final  words  on  the  SDLC  contain  both  advice  and 
caution : 

The  systems  approach  is  a  problem  oriented  one.  It  is  a 
highly  creative  process,  and  the  outcome  is  dependent  upon 
the  people  involved  as  well  as  on  the  resources  avail¬ 
able  ....  Moreover  ,  in  any  given  situation,  the  available 
data  and  theoretical  framework  are  likely  to  be  incomplete 
and  somewhat  ambiguous  so  that  certainty  is  out  of  the 
question.  Imagination,  judgement  and  courage  are  needed. 
The  set  of  possible  future  environments  in  which  proposed 
solutions  must  remain  valid  have  to  be  imagined,  and  their 
potential  effects  evaluated.  Alternative  solutions  must 
be  generated,  characterized  and  evaluated.  Even  the  way 
the  problem  domain  under  study  is  subdivided  for  concep¬ 
tual  manageability  is  a  matter  of  considerable  importance 
that  demands  responsible  judgement  and  originality.  The 
traditional  subdivisions  along  jurisdictional  or  organiza¬ 
tional  lines,  or  in  terms  of  standard  academic  disci¬ 
plines,  are  not  necessarily  the  best  and  are  certainly  not 
the  only  options.  Each  aspect  has  its  place  and  must  be 
considered.  Clearly,  creativity  is  called  for  at  many 
points  in  the  process  of  achieving  a  problem  solution, 
f  Ref .  26 :  p .  9 ] 

A  vast,  complex  system  has  many  elements  with  significant 
interactions  that  are  often  not  understood.  Isolating  the 
elements  for  analysis  may  lead  the  systems  analyst  to 
overlook  the  interactions  that  occur  when  the  elements  are 
combined  into  a  system.... In  particular,  a  system  that 
involves  human  behavior  (e.g.,  an  organization)  involves 
varying  and  changing  variables  that  interact  with,  and/or 
compromise,  the  system.  One  of  the  key  realizations  con¬ 
tributed  by  the  systems  approach  is  that  the  interactions 
among  elements  in  a  system  can  be  as,  or  more,  important 
than  the  elements  themselves.  A  system  is  more  than  ]ust 
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D.  CONTROL 


Figure  2  shows  the  major  decision  points  as  diamonds  and 
the  phases  as  boxes.  These  decision  points  indicate  feasi¬ 
bility  reviews  and  are  only  made  after  each  of  the  first 
three  phases.  The  decision  to  proceed  should  be  made  by  a 
top  level  manager  or  a  high  level  steering  committee.  On 
the  other  hand,  the  SDLC  study  should  be  conducted,  if  at 
all  possible,  by  a  team  of  people: 

If  the  project  proposal  is  approved,  management  generally 
organizes  a  project  team  and  assigns  responsibility  for 
the  project  to  it.  The  specific  personnel  or  type  of 
personnel  to  be  included  on  the  project  team  should  be 
defined  under  the  resource  requirements  section  of  the 
project  proposal.  [Ref.  22:  p.  123] 

The  organization  of  a  project  team  is  a  prerequisite  to 
good  systems  analysis.  Different  types  of  expertise  are 
required  to  thoroughly  consider  all  system  variables.  For 
example,  the  systems  analyst  provides  primarily  computer 
technology-oriented  skills.  Without  adequate  represen¬ 
tation  from  the  various  departments  affected  by  the  in¬ 
formation  system,  various  dimensions  of  their  needs  and 
requirements  are  apt  to  be  overlooked.  [Ref.  23:  p.  123] 

Figure  3  is  a  partially  modified  version  of  a  figure 

developed  by  James  C.  Wetherbe  [Ref.  24:  p.  11].  The  main 

concept  of  Figure  3  is  that  of  iteration  and  hierarchical 

decomposition.  As  the  SDLC  study  starts  at  the  top  of 

Figure  3  it  progresses  to  the  bottom,  through  each  phase, 

until  some  new  development  causes  a  return  to  an  earlier 

phase  or  to  the  beginning.  This  is  shown  by  the  direction 

of  the  arrows.  This  concept  is  explained  by  Wetherbe: 

The  steps  in  the  cycle  (SDLC)  are  neither  discrete  nor 
one-time  processes.  Rather,  the  systems  development  cycle 
is  iterative  and  evolutionary.  The  steps  in  the  cycle, 


Each  chapter  following  this  chapter,  with  the  exception 
of  the  conclusion  chapter,  deals  with  one  of  the  phases  of 
the  SDLC.  Since  these  chapters  contain  explanations  of  the 
purpose  and  objectives  of  each  phase,  only  a  broad  overview 
will  be  provided  in  this  chapter.  Five  phases  have  been 
used  in  this  study.  Figure  1  provides  a  breakdown  of  the 
activities  of  each  phase.  These  activities  have  in  some 
cases  been  modified  to  reflect  considerations  peculiar  to  an 
IC.  The  purpose  of  the  investigation  phase  is  to  define  the 
problem,  identify  requirements,  and  determine  general  feasi¬ 
bility  of  one  or  more  solutions.  The  purpose  of  the  analy¬ 
sis  and  general  design  phase  is  to  develop  a  more  detailed 
analysis,  create  a  general  design  for  an  IC,  and  reconfirm 
feasibility  based  on  the  additional  information  acquired. 

The  purpose  of  the  detailed  design  and  testing  phase  is  to 
reduce  the  general  design  to  a  detailed  design,  to  test  the 
system  (usually  with  a  prototype),  to  examine  feasibility 
one  last  time,  and  make  any  last  minute  changes.  The  pur¬ 
pose  of  the  installation  and  implementation  phase  is  to 
convert  from  the  old  system  to  the  new  IC  system  as  pain¬ 
lessly  and  professionally  as  possible.  The  purpose  of  the 
last  phase,  the  review  phase,  is  to  immediately  evaluate  the 
methodology  and  at  a  later  time  to  review  and  evaluate  the 
operation  and  success  of  the  IC  in  meeting  its  objectives. 
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INVESTIGATION  PHASE 

1 .  Initial  Investigation 

2.  Feasibility  Study 

3.  Recommendation 


ANALYSIS  AND  GENERAL  DESIGN  PHASE 

4.  Existing  System  Review 

5.  New  System  Requirements 

6.  New  System  Design 

7.  Detailed  Design  and  Testing  Planning 


DETAILED  DESIGN  AND  TESTING  PHASE 

a.  Technical  Design 

9.  Performance  Specification  and 
Measurement  Planning 

1 0 .  Staffing 

1 1 .  Prototyping  and  System  Testing 

12.  General  Implementation  Planning 


INSTALLATION  AND  IMPLEMENTATION  PHASE 

1 3 .  Marketing 

1 4 .  Training 

15.  Staffing  and  Consulting 

1 6 .  Hardware 

1 7 .  Software 

18.  Managing  and  Controlling 

19.  Opportunities 


REVIEW  PHASE 

20.  Development  Recapitulation 

21 .  Post  Implementation  Review 


Figure  1.  SDLC  Phases  and  Activities 
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foregoing  and  the  house  is  built  and  cared  for  in  the  manner 
previously  planned. 

Although  this  example  is  simplistic,  it  does  explain  the 
procedure  and  general  thought  process  that  makes  the  SDLC  a 
valuable  methodology  and  useful  in  the  development  of  an  IC. 
Iteration,  going  back  to  the  beginning  or  as  far  as  neces¬ 
sary,  and  hierarchical  decomposition,  "the  breaking  down,  or 
partitioning,  of  a  large  problem,  or  project,  into  a  series 
of  structured,  related,  manageable  parts"  [Ref.  19:  p.  52] 
were  demonstrated  in  the  example.  At  each  major  decision 
point  in  the  example,  the  feasibility  of  continuing  the 
design  as  it  had  been  developed  up  to  that  point  had  to  be 
determined . 

C.  PHASES  AND  ACTIVITIES 

Figures  1  and  2  are  partially  modified  versions  taken 
from  a  book  by  Michael  J.  Powers,  David  R.  Adams,  and  Harlan 

D.  Mills  [Ref.  20:  pp.  42,  50].  Figure  1  presents  the 
phases  and  activities  of  the  SDLC  utilized  in  this  study. 

"A  phase  is  a  set  of  activities  that  brings  a  project  to  a 
critical  mi lestone . . . . An  activity  is  a  group  of  logically 
related  tasks  that,  when  completed,  lead  to  accomplishment 
of  a  specific  objective."  [Ref.  21:  pp.  50-51]  Figure  2 
indicates  checkpoints  where  a  conscious  decision  whether  to 
proceed,  delay,  speed  up,  postpone,  or  abandon  should  be 


instead  reviews  the  shelter  requirements.  For  example,  a 
house  may  not  be  needed  in  the  tropics  or  there  may  be  other 
options  like  a  trailer  home  or  renting.  The  analyst  deter¬ 
mines  that  a  dwelling  is  needed  and  because  there  are  other 
system  requirements  (e.g.,  standard  of  living,  social  sta¬ 
tus,  family  size,  weather,  cost,  etc.)  the  analyst  starts 
describing  a  system  that  generally  fits  the  requirements. 

The  next  step  is  to  determine  details,  such  as  number  of 
toilets  and  amount  of  insulation  required.  At  this  point 
the  analyst  realizes  that  this  person's  car  must  also  be 
protected  and  that  it  should  be  part  of  the  shelter  system. 
The  analyst  goes  as  far  back  as  necessary  to  re-analyze  the 
system.  The  analyst  determines  that  a  garage  or  carport 
would  do  nicely.  When  integrated  with  the  original  require¬ 
ment  the  analyst  realizes  that  the  garage  or  carport  must  be 
attached  to  the  house  in  order  to  provide  shelter  for  the 
person  when  walking  from  the  car  to  the  house.  After  re¬ 
viewing  requirements  and  creating  several  designs  or  op¬ 
tions,  the  analyst  considers  all  factors  such  as  cost, 
amount  of  shelter  and  other  uses  and  chooses  the  proper 
house  and  car  storage  system. 

Since  this  is  a  life  cycle  study,  things  such  as  long¬ 


term  maintenance,  property  appreciation,  and  expected  life 
were  evaluated  based  on  the  overall  objectives  of  the  person 
needing  the  shelter.  The  choice  is  made  based  on  the 


industries,  or  even  society  as  a  whole.  Further,  business 
systems  are  in  a  constant  state  of  change--they  are 
created,  operated,  revised,  and  often  eliminated. 

[ Ref .  17:  pp .  32-33] 

The  value  and  flavor  of  the  systems  approach  are  described 

by  the  following: 

The  systems  approach  is  a  perspective--a  way  of  identi¬ 
fying  and  viewing  complex,  interrelated  functions  as  inte¬ 
gral  elements  of  systems.  Although  there  is  concern  for 
the  individual  parts  of  a  system,  emphasis  is  on  the 
integration  of  the  components  to  produce  the  end  products 
of  the  systems  themselves ... .Systems  analysis  provides  a 
set  of  strategies  and  techniques  for  dealing  with  complex 
problems,  based  on  hierarchical  partitioning  methods  ap¬ 
plied  through  various  levels. of  abstraction  to  analyze 
problems  and  synthesize  solutions ... .A  basic  principle  of 
systems  project  management  is  that  the  systems  development 
life  cycle  should  be  a  guide,  not  a  cookbook ....  systems 
analysis  is  a  process  that  involves  repeating,  or  iter¬ 
ating,  a  series  of  process  steps  to  build  an  understanding 
of  current  systems  and  procedures  and  to  define  new  sys¬ 
tems.  [Ref.  18:  pp .  14,  22,  72,  167] 


B.  EXAMPLE 

The  best  way  to  explain,  in  this  thesis,  how  the  SDLC  is 
applied  to  ICs  is  to  provide  a  facetious  but  pedagogic  ex¬ 
ample,  Consider  the  example  of  a  person  standing  outside  in 
the  cold  in  a  strong  breeze.  He  starts  out  by  saying  he  has 
a  problem:  he  is  cold.  This  is  what  an  untrained  person 
says.  But  a  trained  person,  similar  to  a  systems  analyst, 
would  say  that  being  cold  is  the  symptom  and  that  the  real 
problem  is  that  he  needs  shelter.  Therefore,  the  problem  is 
now  well  defined. 

The  next  step  is  to  determine  the  requirements.  The 
untrained  person  says  he  needs  to  buy  a  house.  The  analyst 
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II.  SYSTEMS  DEVELOPMENT  LIFE  CYCLE  METHODOLOGY 


A.  BACKGROUND 

The  SDLC,  applied  to  an  IC,  is  a  combination  of  the 
systems  approach  and  the  life  cycle  approach.  The  systems 
approach  causes  one  to  view  the  IC  as  a  system  which  con¬ 
tains  its  own  subsystems  and  at  the  same  time  is  part  of  a 
larger  system.  The  life  cycle  approach  considers  the  fact 
that  the  IC  is  created,  is  developed,  grows,  matures,  and 
either  expands  into  something  else  or  becomes  obsolete. 
Although  one  can  not  always  predict  the  future,  especially 
concerning  a  concept  as  new  as  the  IC,  there  are  certain 
aspects  that  can  be  predicted  which  can  contribute  to  a 
better  IC. 

This  thesis  views  the  systems  approach  much  the  same  way 
as  Kenneth  Boulding  did  in  1956,  as  summarized  by  James 
Wetherbe  in  1984: 

The  systems  approach  is  the  way  of  thinking  about  the  job 
of  managing.  It  provides  a  framework  for  visualizing 
internal  and  external  environmental  factors  as  an  inte¬ 
grated  whole.  It  allows  recognition  of  the  function  of 
subsystems,  as  well  as  the  complex  suprasystems  within 
which  organizations  must  operate.  Systems  concepts  foster 
a  way  of  thinking  which,  on  the  one  hand,  helps  the  manag¬ 
er  to  recognize  the  nature  of  complex  problems  and  thereby 
to  operate  within  the  perceived  environment.  It  is  impor¬ 
tant  to  recognize  the  integrated  nature  of  specific  sys¬ 
tems,  including  the  fact  that  each  system  has  both  inputs 
and  outputs  and  can  be  viewed  as  a  self-contained  unit. 

But  it  is  also  important  to  recognize  that  business  sys¬ 
tems  are  a  part  of  larger  systems--possibly  industrywide, 
or  including  several,  maybe-many,  companies  and/or 


...at  present  a  wide  array  of  organization  patterns  are 
possible  as  an  organization  advances  toward  the  totality 
of  information  servicesl  We  see  this  heterogeneity  as 
transitional,  with  the  eventual  merger  of  these  islands 
into  a  central  hub  occurring  in  most  organizations;  cer¬ 
tainly  for  policy  making,  planning,  and  control  purposes, 
and  in  many  settings,  for  line  control  and  execution.  The 
timing  of  these  moves  in  any  organization  is  situation  de¬ 
pendent,  involving  current  corporation  structure  and  lead¬ 
ership  style,  speed  at  which  the  firm  has  been  staying 
modern  in  these  technologies,  individual  retirement  plans, 
current  development  priorities,  and  so  forth.  [Ref.  16: 
p.  36] 


It  is  important  to  acknowledge  the  present  state-of-the- 


art  in  information  technology  in  order  to  have  some  idea  of 

where  the  IC  concept  is  heading.  F.  Warren  McFarlan  and 

James  L.  McKenney,  Harvard  University,  have  written  about 

the  concept  of  phased  merging  of  different  technologies. 

Their  position  is  as  follows: 

Organizationally,  there  are  multiple  paths  which  can  be 
followed  in  effecting  the  merger  of  the  three  islands 
iData  Processing,  Telecommunications,  and  Office  Automa¬ 
tion)  of  technologies  as  a  firm  moves  toward  a  merged 
information  services  function.  [Ref.  15:  p.  34] 

The  multiple  paths  they  make  reference  to  are  the  following: 

1 .  Merging  Data  Processing  and  Telecommunications 

2.  Merging  Telecommunications  and  Office  Automation 

3.  Merging  Data  Processing  and  Office  Automation 

In  this  context  the  three  singular  IC  classifications  of 
Host-Connected,  Stand-Alone,  and  Networks  can  be  compared 
with  Data  Processing,  Office  Automation,  and  Telecommunica¬ 
tions,  respectively.  The  state-of-the-art  for  implementing 
these  paths  exists  today.  On  the  other  hand,  complete 
integration  of  the  three  paths  does  not  exist.  Although  the 
information  processing  industry  has  been  v/orking  toward  this 
goal,  only  limited  integration  has  been  achieved. 

Although  McFarlan  and  McKenney  are  not  addressing  ICs  in 
particular  but  rather  information  technology  as  a  whole, 
their  logic  can  be  extended  to  IC  orgrnization  and  technolo¬ 
gy.  They  summarize  their  thoughts  with  the  following; 
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to  sample  and  evaluate  different  machines  (usually  with 
strong  orientation  toward  microcomputers  and  software). 

A  Network  classification  may  involve  outside  timesharing 
services.  Coordination  and  proper  use  of  these  services  are 
emphasized.  Another  type  of  Network  classification  involves 
local  area  networks  (LANs)  that  are  not  connected  to  host 
computers  but  are  established  to  fulfill  a  need  to  maximize 
local  communications. 

The  most  common  classification  is  the  Mixed  classifica¬ 
tion.  It  is  also  the  most  advanced  implementation  of  the 
IC.  It  is  a  combination  of  any  two  or  all  three  of  the 
other  classifications.  The  range  of  sophistication  in  the 
mixed  classification  is  broad.  At  the  low  end,  the  micro¬ 
mainframe  connection  involves  the  transfer  of  data  files 
which  can  be  used  by  the  software  and  operating  systems  of 
either  the  microcomputer  or  the  mainframe.  At  the  high  end, 
all  three  of  the  other  classifications  can  be  implemented  in 
an  integrated  fashion. 

Some  implementations  will  be  difficult  to  categorize  in 
this  manner.  For  example,  implementations  which  are  purely 
conceptual,  trivially  simple,  or  based  on  distributed  appli¬ 
cations  may  be  hard  to  assign  to  any  of  these  categories. 
Nevertheless,  these  implementations  will  favor  one  of  the 
four  classifications  listed  above  and  can  be  categorized 
with  one  of  these  four. 


used  as  a  site  for  training,  for  daily  user  access,  for  user 
or  corporate  hardware  and  software  evaluation,  or  for  hard¬ 
ware  and  software  selection.  ICs  frequently  include  a  com¬ 
bination  of  more  than  one  of  these  purposes. 

ICs  can  be  partitioned  and  labeled  in  several  different 
ways.  For  purposes  of  description  they  are  easily  classi¬ 
fied  as  follows: 

1 .  Host-Connected 

2.  Stand-Alone 

3.  Networked 

4 .  Mixed 

A  Host-Connected  classification  means  that  the  IC  is 
composed  of  terminals  (some  of  which  may  be  microcomputers 
used  as  terminals)  connected  to  the  host  computer,  usually  a 
mainframe  computer.  All  work  is  done  through  the  use  of  the 
host  computer.  A  good  example  of  this  type  is  installed  at 
Anheuser-Busch  where  "it  is  virtually  impossible  for  employ¬ 
ees  to  buy  a  microcomputer."  [Ref.  14;  p.  13] 

A  Stand-Alone  classification  involves  the  use  of  one 
machine  by  one  individual  to  process  information.  This  is 
usually  a  microcomputer.  This  type  of  IC  frequently  in¬ 
volves  provision  of  some  type  of  purchase  service,  mainte¬ 
nance  service,  introductory  training,  coordination  for 
compatibility,  setup  (including  software  installation), 
instruction  on  equipment  care  and  use,  and  the  opportunity 
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the  sum  of  its  parts  and  must  be  considered  as  such.  [Ref 
27:  pp.  33-34] 

Although  the  process  of  systems  analysis  is  straightfor¬ 
ward  in  concept,  it  can  be  exceedingly  complex  and  diffi¬ 
cult  in  application.  It  must  be  emphasized  that  systems 
analysis  is  not  a  panacea.  It  is  not  a  black  box  into 
which  one  drops  problems  at  one  end  and  automatically 
receives  solutions  at  the  other.  It  is,  as  was  pointed 
out,  a  framework  in  which  a  multi-disciplinary  group  of 
scientists,  engineers  and  technicians  can  achieve  a  uni¬ 
fied  problem-oriented  focus,  and  this  common  research 
orientation  maximizes  the  possibilities  for  achieving 
successful  solutions  of  complex  problems.  The  real  value 
of  systems  analysis  lies  in  the  fact  that  it  forces  a 
manager  to  structure  his  thinking  to  the  problem  at  hand, 
to  prepare  a  solution  given  a  particular  set  of  circum¬ 
stances,  to  prepare  alternatives  and  to  establish  require 
ments .  [Ref.  28:  p.  12] 


26 


Ill . 


INVESTIGATION  PHASE 


A.  PURPOSE  OF  INVESTIGATION  PHASE 

The  chief  purpose  of  the  investigation  phase  is  to  deter¬ 
mine  whether  a  problem  or  need  requires  a  full  systems 
development  effort  or  whether  another  course  of  action  is 
appropriate.  One  alternative  course  of  action  may  be  to 
do  nothing,  to  leave  operations  as  they  are.  Another 
alternative  may  be  to  undertake  a  project  to  upgrade,  or 
maintain,  the  existing  system  rather  than  to  develop  a  new 
one.  [Ref.  29:  p.  44] 

During  this  phase,  the  problem  is  defined,  needs  are 
identified,  and  possible  solutions  are  presented.  This 
phase  has  two  parts.  The  first  part  is  the  initial  investi¬ 
gation.  The  second  part  is  the  feasibility  study.  Determi¬ 
nation  of  the  need  to  conduct  a  feasibility  study  is  the 
result  of  the  first  part.  At  the  conclusion  of  the  investi¬ 
gation  phase  which  is  also  the  conclusion  of  the  second 
part,  a  decision  must  be  made  whether  or  not  to  proceed  with 
the  next  phase  of  the  SDLC. 


B.  INITIAL  INVESTIGATION 

1 .  Source  Identification 

The  source  of  the  request  or  order  to  implement  an 
IC  or  to  initiate  an  SDLC,  may  come  from  any  department  or 
individual  within  the  corporation  or  organization.  It  is 

» 

important  to  identify  this  party  early,  preferably  at  this  " 

point  the  SDLC.  Knowing  this  party's  identity  can  assist  -! 


in  the  determination  of  the  initial  support  groups  and 


possible  behavioral  problems.  If  this  party  is  top  manage¬ 
ment,  then  one  can  expect  high  level  support  and  can  plan 
accordingly.  If  not,  then  a  different  outlook  will  be 
required.  If  this  party  is  a  group,  then  it  is  valuable  to 
know  who  the  proponents  are  or  at  least  the  ratio  of  propo¬ 
nents  to  opponents.  If  an  IC  is  established  under  the 
misconception  that  the  entire  group  supports  the  idea  when, 
in  fact,  they  do  not,  the  consequences  may  be  disastrous. 
Identification  of  this  group  or  individual  will  also  help  to 
identify  some  of  the  political  issues  that  may  have  an 
impact  on  the  IC  decision.  Early  identification  of  the 
behavioral  aspects  and  of  the  source  of  the  IC  request  will 
mire  than  likely  have  a  profound  impact  on  the  determination 
of  the  approach  to  be  taken  and  the  problem  to  be  solved. 
Current  literature  stresses  the  sensitivity  of  ICs  to  var¬ 
ious  factions  of  resistance,  political  infighting,  and  the 
necessity  of  top-management  support. 

2 .  Motivation 

It  is  important  to  understand  this  party's  motiva¬ 
tion.  There  will  usually  be  more  than  one  reason  for  want¬ 
ing  to  implement  an  IC.  Among  the  various  reasons  for 
implementing  the  IC,  two  are  mentioned  more  than  others. 

One  is  to  reduce  the  applications  backlog  and  the  other  is 
to  control  the  proliferation  of  microcomputers.  Some  addi¬ 
tional  reasons  are  to  coordinate  technological  growth,  to 
provide  end  user  training,  to  provide  data  security  and 


integrity,  to  give  users  control  of  their  own  data,  to 
provide  consultation  to  end  users,  to  administer  end  user 
computing,  to  reduce  the  effect  of  system  analyst  and  pro¬ 
grammer  shortages,  to  provide  a  test  bed  for  new  hardware 
and  software  products,  to  reduce  the  load  on  the  host  com¬ 
puter,  to  improve  data  processing  department's  relations 
with  user  departments,  and  to  provide  a  central  point  for 
end  user  standards , 

In  addition  to  the  advertised  reasons  for  implement¬ 
ing  an  IC,  it  is  vital  to  uncover  hidden  motivations,  as 
well.  A  very  common  hidden  laotivation  is  internal  empire 
building  or  managerial  territorial  conflicts.  Another  hid¬ 
den  motivation  is  the  need  or  desire  to  match  or  even  sur¬ 
pass  a  competitor's  position.  This  may  be  nothing  more  than 
a  race  to  be  the  first  to  install  the  latest  technology  or, 
if  the  competition  cannot  be  equalized,  it  may  cause  the 
corporation  to  fail.  Another  hidden  motivation  is  to  effect 
an  organizational  change.  This  is  often  done  to  accommodate 
personalities  or  poor  individual  performance.  Usually,  the 
implementation  of  the  IC  has  little  effect  on  sustained 
performance  and  rarely  does  it  solve  personality  problems. 
The  impact  of  not  correcting  these  situations  prior  to 
taking  any  action  can  be  devastating  to  the  success  of  the 
IC.  Finally,  there  may  be  other  hidden  motivations  and 
these  should  also  be  identified  and  corrective  action  taken 
if  necessary. 
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3 .  The  Envisioned  Information  Center 

The  interested  party  may  already  have  their  own  idea 
of  what  will  constitute  the  IC.  Although  this  may  be  less 
than  optimal,  it  is  important  to  record  and  thoroughly 
understand  this  party's  idea.  At  this  point  in  the  SDLC, 
there  should  be  no  attempt  to  change  their  position.  It  may 
turn  out  that  their  intuition  or  analysis  is  accurate  and 
that  any  conflict  now,  may  encourage  future  conflict,  unnec¬ 
essarily.  Likewise,  it  is  likely  that  this  party  will  view 
the  IC  as  a  one  time  implementation  when  in  actuality  it 
should  be  viewed  as  an  evolutionary  process  [Ref.  30: 
pp .  211-212].  Therefore,  this  party's  view  will  probably 
change  as  the  SDLC  study  progresses. 

4 ,  Research  on  the  Information  Center  Concept 

It  is  virtually  impossible  to  address  the  issue  of 
an  IC  unless  one  understands  the  IC  concept.  Therefore,  it 
is  necessary  to  learn  as  much  about  ICs  as  possible.  At  a 
minimum  there  should  be  a  literature  search.  This  can  be 
started  at  the  local  library  or  university.  This  research 
can  be  extended  to  include  the  hiring  of  a  consultant  to 
give  a  presentation  on  the  IC  concept.  Attending  workshops 
or  seminars  can  also  be  rewarding,  as  well  as  discussions 
with  others  who  have  already  implemented  an  IC.  Visits  to 
IC  sites  should  be  arranged  if  possible.  Vendors  can  pro¬ 
vide  a  different  view.  It  may  also  be  feasible  to  join  a 
local  users  group.  IC  users  groups  and  special  interest 


groups  have  been  gaining  popularity  and  it  is  not  difficult 
to  find  one  in  almost  any  section  of  the  United  States 
[Refs.  31:  p.  26,  32:  p.  26,  33:  p,  12].  It  may  also 
be  useful  to  join  certain  computer  related  professional 
associations.  Lastly,  any  opportunity  not  already  mentioned 
should  be  considered.  Properly  conducted  research  on  the 
nature  of  ICs  and  learning  from  the  successes  and  failures 
of  other  groups  can  save  a  considerable  amount  of  time  and 
money . 

5  .  Problem  Def inition 

At  this  point  in  the  study,  the  problem  to  be  ad¬ 
dressed  should  be  formally  stated  or  defined.  This  can  be 
somewhat  difficult  because  of  the  foregoing  and  because  it 
is  often  difficult  to  separate  symptoms  from  causes.  It 
will  involve  determination  of  general  business  objectives, 
information  system  objectives,  and  user  needs.  This  is  not 
the  place  to  espouse  solutions.  It  is  quite  possible  that 
the  problem  may  require  something  different  than  an  IC. 

a.  Goals,  Strategy,  and  Competitive  Position 

Alignment  of  the  problem  to  business  objectives 
IS  critical  to  proper  perspective.  Corporate  goals,  strate¬ 
gy,  and  competitive  position  will  be  a  strong  guide  in 
determining  areas  that  should  be  exploited.  It  will  also  be 
a  large  determinant  of  the  economical  justification  of  the 
solution.  For  example,  if  the  corporate  goal  is  to  capture 


seventy  percent  of  the  market,  then  alternate  goals  such  as 


maximizing  profit  will  be  secondary  considerations.  If  top 
management  will  not  disclose  the  corporation's  goals  (possi¬ 
bly  due  to  security  concerns)  or  has  not  performed  any  long¬ 
term  strategic  planning,  then  it  is  recommended  that  goals 
should  be  established  based  on  the  best  available  informa¬ 
tion.  [Ref.  34:  p.  11]  Competitive  position  is  determined 
by  the  success  of  the  corporation's  strategy.  McFarlan 
gives  a  synopsis  of  each  of  Michael  E.  Porter's  three  cate¬ 
gories  of  competitive  strategies  as  follows: 

One  (strategy)  is  cost  based,  when  a  company  can  produce 
at  a  much  lower  cost  than  its  competition.  Companies 
selling  commodities  and  high-technology  products  can  use 
such  strategies.  A  second  type  is  based  on  product  dif¬ 
ferentiation,  when  a  company  offers  a  different  mix  of 
product  features  such  as  service  and  quality.  (Companies 
selling  baby  care  products  and  cosmetics  can  use  this 
strategy.)  The  third  type  is  specialization  in  only  one 
niche  of  a  market,  distinguishing  itself  by  unusual  cost 
or  product  features.  Its  strategies  may  be  called  fo¬ 
cused.  (An  example  would  be  focusing  on  a  narrow  range  of 
industrial  grade  papers  to  avoid  advertising  battles.) 
[Ref.  35:  p.  100] 

Porter  identifies  these  three  strategies  as  "generic  strate¬ 
gic  approaches"  [Ref.  36:  p.  35]  and  labels  them  as  follows: 

1 .  overall  cost  leadership 

2.  differentiation 

3.  focus 

It  is  important  to  understand  which  strategy  is  being 
used  by  the  corporation  so  that  the  solution  will  maximize 
the  corporation's  competitive  position.  Additionally, 
awareness  of  the  competitive  position,  such  as  knowing  the 
market  share  or  profit  differentials  of  the  industry,  can 


assist  in  development  of  areas  that  will  create  more  return 
on  the  investment.  If  the  solution  supports  this  position, 
then  it  will  provide  the  opportunity  to  exploit  the  competi 
tion's  weaknesses  and  to  capitalize  on  the  corporation's 
strengths . 

b.  Information  System  Strategy 

Understanding  the  corporate  strategy  and  goals 

is  only  part  of  the  overall  picture.  The  IC  must  also  fit 
into  the  information  systems  strategy.  The  data  processing 
workloads,  emphasis  areas,  and  future  plans  should  be  con¬ 
sidered.  The  IC  should  complement  the  data  processing, 
telecommunication,  and  office  automation  efforts  unless 
obsolescence,  economy  reasons,  or  some  other  valid  reason 
make  this  undesirable. 

c.  Management  Structure 

Understanding  the  management  structure  can  help 
to  identify  the  users.  A  common  method  to  describe  a  corpo 
ration's  management  structure  is  depicted  by  a  pyramid  seg¬ 
regating  the  three  levels  of  management;  top  management, 
middle  management,  and  operational  management.  This  idea  i 
carried  one  step  further  by  Dan  Trimmer  [Ref.  37:  p.  43] 
where  in  Figure  4  he  shows  the  trend  of  data  processing 
support  for  each  level.  Figure  4  shows  a  shift  toward  more 
data  processing  services  for  top  and  middle  management. 

This  trend  points  to  the  growth  rate  of  these  classes  of 
users  and  in  general  the  need  to  solve  their  problems  and 
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Figure  4.  Data  Processing  Trends 


fulfill  their  data  processing  needs.  It  also  emphasizes  the 
future  importance  of  ICs  since  they  mainly  support  top  and 
middle  management.  This  concept  can  help  provide  an  esti¬ 
mate  of  the  number  of  users. 

d.  User  Needs  Analysis 

All  information  needs  should  be  identified. 

This  may  seem  like  extraneous  work,  but  in  the  end  it  will 
save  time  and  will  help  to  coordinate  and  integrate  the 
requirements  of  diverse  groups  within  the  organization  or 
corporation.  This  avoids  duplication,  provides  a  universal 
picture  of  the  organization's  needs,  provides  .  vehicle  for 
a  more  complete  analysis,  and  provides  a  more  accurate 
format  for  needs  prioritization.  It  is  important  to  concen¬ 
trate  on  scope  rather  than  level  of  abstraction  or  amount  of 
detail.  The  latter  is  dependent  on  corporation  size,  auto¬ 
mation  maturity,  and  other  considerations.  Once  these  needs 
have  been  determined,  the  current  methods  for  meeting  these 
needs  must  be  identified.  In  some  cases  these  methods  will 
be  manual;  in  other  cases  they  will  automated.  It  is  quite 
possible  that  they  will  not  have  been  addressed  at  all  or 
have  been  addressed  in  a  deficient  manner.  Determination  of 
needs  is  difficult  to  do  well  because  of  the  high  degree  of 
subjectivity  and  a  requirement  to  be  creative.  Neverthe¬ 
less,  extra  time  spent  in  this  activity  will  reduce  the 
number  of  corrections  and  facilitate  revisions  during  the 
SDLC. 
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Although  each  implementation  of  the  IC  concept 
is  different,  user  needs  can  be  categorized  in  general 
terms.  These  needs  are  segregated  into  system  types  by 
Robert  M.  Alloway  and  Judith  A.  Quillard  in  Figure  5 
[Ref.  38:  p.  30).  The  types  of  requirements  commonly  served 
by  ICs  are  listed  in  Figure  5  under  the  categories  of  in¬ 
quiry  and  analysis  under  the  managerial  support  systems. 

The  transaction  processing  system  supports  the  lowest  level 
of  the  previously  mentioned  managerial  pyramid,  the  opera¬ 
tional  level  which  is  generally  not  supported  by  an  IC. 

C.  FEASIBILITY  STUDY 
^  .  Purpose 

The  purpose  of  the  feasibility  study  is  to  determine 
whether  the  new  system  ( IC)  should  be  developed,  to  develop 
alternative  solutions,  to  recommend  the  best  solution,  and 
to  provide  a  projected  budget  for  the  new  system.  It  is  a 
determination  of  whether  a  project  is  possible,  practical, 
and  realistic.  The  feasibility  study  is  a  miniature  systems 
analysis  study  that  builds  on  the  results  of  the  initial 
investigation.  It  covers  essentially  the  same  ground  as  the 
analysis  and  general  design  phase,  but  in  far  less  depth. 
[Ref.  39:  pp .  120-145] 
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Monitor  The  system  monitors  daily  detail  activity 
producing  standard  reports  on  a  fixed 
schedule  (daily,  weekly,  or  monthly). 

Exception  The  system  processes  detail  activity  reports 
where  the  definition  of  exception  conditions 
is  fixed. 

Inquiry  The  system  provides  a  database  with  flexible 
inquiry  capability,  enabling  managers  to 
design  and  change  their  own  monitoring  and 
exception  reports. 

Analysis  The  system  provides  powerful  data  analysis 
capabilities  (modeling,  simulation, 
optimization  or  statistical  routines)  and 
the  appropriate  database  to  support 
managerial  decision-making. 


Figure  5.  Description  of  Systems  Types 
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2 .  Alternative  Solutions 

Since  the  initial  investigation  has  been  completed 
and  the  problem  has  been  defined,  solutions  are  now  consid¬ 
ered.  Among  the  possibilities  are  the  following: 

a.  Do  nothing  -  Maintain  the  status  quo. 

b.  Expand  the  existing  system  -  Add  more  resources  of  the 
same  type  (people,  equipment,  software). 

c.  Contract-out  -  Pay  for  outside  services. 

d.  Reorganize  existing  services  -  Decentralization  is  the 
most  common  occurrence. 

e.  Establish  new  policies  -  Often  used  to  control  micro 
proliferation. 

f.  Install  an  IC  -  This  is  the  most  that  can  possibly  be 
done  in  terms  of  a  new  system,  under  this  study. 

3 .  The  New  System 

The  needs  analysis  conducted  in  the  initial  investi¬ 
gation  is  the  source  for  this  part  of  the  SDLC.  By  now,  a 
general  idea  of  what  the  IC  will  entail  should  be  formu¬ 
lated.  The  type  of  IC  (ie.  Host -Connected ,  Stand-Alone, 
Networked,  or  Mixed),  should  be  identified.  A  rough  idea  of 
the  size  and  contents  of  a  physical  site  and  the  number  of 
staff  personnel  should  be  decided.  Approximate  figures  for 
number  of  users,  IC  usage  rates,  supply  requirements,  organ¬ 
izational  location,  costs,  and  benefits  should  be  developed. 
The  following  categories  of  feasibility  [Ref.  40:  p.  122] 
should  be  addressed: 

a.  Financial  feasibility 

b.  Operational  feasibility 
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c.  Technical  feasibility 

d.  Schedule  feasibility 

e.  Human  factors  feasibility 

In  determining  overall  feasibility,  the  old  system  must  be 
considered.  James  C.  Wetherbe,  writes  the  following  on  this 
issue ; 

In  the  excitement  of  implementing  new  technology,  it  is 
often  easy  to  overlook  certain  capabilities  or  function¬ 
alities  of  the  old  technology  and  to  leave  them  out  of  the 
new  system.  Such  actions  result  in  disillusionment  witn 
the  new  system  and  nostalgia  for  the  the  old  system. 
Therefore,  it  is  critical  to  conduct  a  thorough  analysis 
of  the  old  system  before  final  design  decisions  are  made 
on  a  new  system.  [Ref.  41;  p.  128) 

In  terms  of  the  IC ,  this  means  that  the  data  processing 

department  resources,  host  and  microcomputer  usage,  software 

support,  and  manual  procedures  of  the  existing  system  are 

reviewed  and  considered. 

4 .  Proj  ected  Budget 

Part  of  the  feasibility  study  is  comprised  of  a 
cost/benefit  analysis.  This  analysis  provides  input  to  the 
development  of  the  projected  budget.  The  projected  -.dget 
should  combine  costs  and  time  and  result  in  financial  mile¬ 
stones  and  a  schedule  of  expenditure  of  funds.  It  is  better 
t3r  jpper  management  and  for  future  performance  evaluation 
minis  u  r-irn’in  ts  ,  if  a  cost  ]  ust  i  f  icat  ion  for  the  IC  is 
ie'/'"  Loped  . 
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usually  very  accommodating  in  providing  information.  Most 
of  the  larger  vendors  are  also  willing  to  let  orgar  ’ ’ations 
and  corporations  use  both  hardware  and  software  on  a  trial 
basis.  In  most  cases  it  is  fairly  easy  to  survey  current 
users  of  these  products  to  determine  their  level  of  satis¬ 
faction.  These  users  can  provide  information  on  vendor 
performance  and  response  and  on  the  benefits  and  drawbacks 
of  the  product  they  are  using. 

The  detailed  physical  layout  should,  at  a  minimum,  in¬ 
clude  blueprints  of  the  floor  layout.  These  blueprints 
should  address  not  only  furniture  placement,  but  also  power 
requirements,  lighting,  work  flow,  noise  levels,  ergonomic 
factors,  safety,  security,  and  comfort.  Current  literature 
stresses  a  separate  training  facili‘-v  for  classroom  type 
training,  location  of  consultants  in  close  proximity  to  each 
other  to  enhance  intra-staff  communication,  adequate  noise 
control  around  work  stations,  provision  of  adequate  space 
for  administration  requirements  (i.e.  supplies  storage, 
equipment  processing  and  repair,  etc.),  and  a  work  station 
for  each  staff  member.  The  location  of  the  IC  has  a  lot  to 
do  with  the  layout  considerations  and  should  also  be  deter¬ 
mined  during  this  phase  of  the  SDLC.  N.  Dean  Meyer,  a 
consultant  in  advanced  automation,  writes  the  following 
about  the  location  of  the  IC: 

The  physical  location  of  the  information  center  is  another 
critical  management  issue.  It  can  be  located  within  the 
office's  of  the  information  staff  or  placed  in  an  area 
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V.  DETAILED  DESIGN  AND  TESTING  PHASE 


A.  PURPOSE  OF  DETAILED  DESIGN  AND  TESTING  PHASE 

The  purpose  of  the  detailed  design  and  testing  phase  is 
to  turn  specifications  into  a  developed  ready-to-use  system 
that  IS  completely  documented,  fully  tested,  and  approved  by 
users  and  management.  This  phase  involves  technical  design, 
performance  specification  and  measurement  planning,  staff¬ 
ing,  prototyping  and  system  testing,  and  general  implementa¬ 
tion  planning. 

B.  TECHNICAL  DESIGN 

The  purpose  of  the  technical  design  activity  is  to 
expand  the  general  design  of  the  previous  phase  to  a  deeper, 
more  detailed  level.  This  activity  results  in  a  design 
specification  that  is  as  complete  and  detailed  as  possible. 
Technical  design  identifies  the  actual  hardware  and 
software,  the  physical  layout,  services  to  be  offered,  com¬ 
munications  architecture,  database  configuration,  adminis¬ 
tration,  controls,  and  management  structure.  Technical 
desL'in  can  be  thought  of  as  answering  detailed  "what"  ques¬ 
tions.  The  "how"  questions  are  reserved  for  the  next  phase, 
i  ns  t  a  I  i  1 1  on  and  implementation. 

One  of  the  easiest  technical  design  tasks  is  the  identi¬ 
fication  of  the  actual  hardware  and  software.  Vendors  are 
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The  level  of  detail  will  depend  on  the  requirements  of  the 
proDlem,  the  size  of  the  planned  IC,  the  amount  of  risk 
involved,  and  the  experience  of  the  development  team.  The 
second  area  concerns  the  method  to  be  used  to  test  the  nev; 
design.  In  most  IC  implem.entations  a  prototype,  a  pilot 
study,  or  a  similar  test  vehicle  should  be  utilized.  This 
allows  experimentation  under  controlled  conditions.  It  also 
reduces  end  user  frustration  when  t.he  IC  begins  to  operate, 
because  operational  problems  should  have  surfaced  and  should 
have  been  eliminated  during  the  testing  phase.  This  plan 
should  make  transition  from  design  to  testing  easier. 


There  will  most  li.<ely  be  some  jesign  tradeoffs  and  deci¬ 
sions  that  must  be  made.  These  decisions  are  more  effec¬ 
tively  maae  at  this  hesi gn  stage  rather  than  at  the  detailed 
design  stage  where  mistakes  are  more  costly. 

The  result  of  this  activity  is  a  general  design  specifi¬ 
cation  and  a  more  accurate  and  detailed  feasibility  study. 
These  documents  form  the  basis  for  management,  user,  and  IC 
implementation  personnel  approval. 

E.  detailed  design  and  testi.ng  planning 

The  purpose  of  this  activity  is  to  establish  a  prelimi¬ 
nary  plan  for  the  ne.xt  phase,  the  detailed  design  and  test¬ 
ing  pliase,  and  to  recommend  a  general  approach  for  testing 
the  newly  designed  IC.  This  plan  should  provide  a  general 
guideline  to  determine  which  areas  require  further  detail 
and  to  determine  the  level  of  detail  required.  This  plan 
should  also  provide  a  general  overview  of  the  testing  activ¬ 
ity  and  should  result  in  establishment  of  general  acceptance 
standards  and  the  framework  for  the  type  of  testing  to  be 
conducted.  One  ob]ective  of  this  olan  is  to  eliminate  as 
many  surprises  as  possible  during  development  in  order  to 
eliminate  surprises  after  development.  Another  objective  of 
this  pirjn  IS  to  ensure  that  major  items  are  not  overlooked. 

The’^e  are  two  areas  of  consideration  for  the  detailed 
design  and  testing  plan.  The  first  area  concerns  the 
identification  of  the  items  which  require  additional  detail. 
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5.  to  improve  the  relationship  between  data  processing 
and  the  user ; 

6.  reduce  the  amount  of  data  and  increase  the  amount 
of  information; 

7.  encourage  an  entrepreneurial  attitude  towards  users; 

8.  restructure  the  data  processing  organization;  or, 

9.  for  any  other  acceptable  reason. 

The  user  requirements  are  then  matched  to  design  re¬ 
quirements.  For  example,  if  a  spreadsheet  analysis  capabil¬ 
ity  IS  required,  then  the  general  design  should  determine 
the  number  and  location  of  immediate  or  potential  users,  tr- 
type  and  amount  of  data  to  be  accessed,  the  data  access 
requirements,  the  requirements  for  integration  with  other 
software,  the  location  of  the  data,  and  the  sophistication 
required  of  the  spreadsheet  software.  This  should  then 
result  in  a  general  design  that  supports  either  mainframe  or 
micro  implementation  using  either  an  integrated  or  stand¬ 
alone  software  package  that  should  or  should  not  be 
networKed  to  other  system.s.  Choosing  the  exact  type  of 
spreadsheet  software  would  not  be  appropriate  for  this  level 
of  design  and  should  be  determined  during  detailed  design. 

This  example  illustrates  the  i nter re lat lonships  of  some 
of  the  various  facets  of  the  general  design  problem  and 
gives  some  indication  of  the  complexity  involved  and  the 
vast  num.ber  of  options  available.  It  is  important  to  try  to 
satisfy  the  important  user  requirements  first.  T'^  i  s 
;iriority  sh.oubi  be  based  on  corporate  goals  and  obj  ert  I'les  . 
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This  activity  results  in  a  new  systems  design  specification 
and  an  updated  feasibility  study.  The  latter  includes  prep¬ 
aration  of  accurate  estimates  for  all  five  dimensions  of 
feasibility--f inancial ,  technical,  operational,  scheduling, 
and  human  factors.  Controls  are  also  considered  to  assure 
accuracy,  completeness,  reliability,  and  quality  of  results 
produced.  [Ref.  50:  pp .  457-487] 

The  separation  of  general  design  from  detailed  design  is 
often  unclear.  One  guide  to  determine  what  to  consider 
under  general  design  is  to  determine  if  a  more  detailed 
level  exists  beyond  the  one  under  consideration.  Another 
guide  is  to  determine  if  further  detail  is  necessary  to  more 
accurately  determine  feasibility  in  order  to  make  a  decision 
on  IC  implementation.  Regardless  of  how  one  ascertains  the 
level  of  detail,  the  question  of  how  to  proceed  still  ex¬ 
ists.  There  is  no  single  methodology  for  this  process. 

One  way  to  proceed  is  to  start  with  an  overall  review  of 
the  requirements.  Since  the  requirements  should  have  been 
developed  with  the  business  goals  and  objectives  in  mind,  it 
seems  logical  to  review  these  goals  and  objectives  again. 

The  IC  goals  and  objectives  should  also  be  examined.  Some 
examples  of  reasonable  goals  are  to: 

1.  maximize  end  user  productivity; 

2.  reduce  the  application  backlog  pressure; 

3.  control  the  proliferation  of  microcomputers; 

4.  educate  the  user  about  data  processing; 
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assistance,  database  interfacing,  data  extract  services, 
security,  data  integrity,  backup  and  recovery  services, 
installation  and  setup  of  hardware  and  software,  provision 
and  availability  of  manuals  and  documentation,  consumable 
supplies  (e.g.  printer  paper  and  ribbons,  diskettes,  disk¬ 
ette  holders,  labels,  etc.),  procurement  of  computer  furni¬ 
ture,  timesharing  services,  electronic  mail  coordination, 
office  automation  control  and  implementation,  providing  hot 
line  services,  applications  libraries,  standards  and  compat¬ 
ibility  management,  marketing  services,  site  licenses  for 
software,  microcomputer  loan  services,  mainframe  performance 
monitoring,  planning  assistance,  and  anything  else  that  may 
be  appropriate.  Because  of  the  different  user  responses  to 
services,  the  requirements  for  some  of  these  services  may  be 
indeterminable  until  actual  installation  and  usage  has  oc¬ 
curred.  The  level  and  quantity  of  services  may  also  be 
difficult  to  estimate  before  their  provision. 

D.  NEW  SYSTEM  DESIGN 

The  purpose  of  new  system  design  is  to  provide  suffi¬ 
cient  information  to  serve  as  a  basis  for  a  decision  on 
whether  to  continue  with  implementation.  The  feasibility 
analysis  is  updated,  and  user  and  management  commitment  and 
approval  are  secured.  The  life  cycle  structure  precludes 
full  technical  design  during  this  activity,  partly  because 
this  level  of  commitment  has  neither  been  made  nor  funded. 
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It  may  be  helpful  to  combine  the  perspectives  of  both  Fig¬ 
ures  5  and  6. 

The  requirements  specification  should  tell  the  user  what 
requirements  the  IC  will  satisfy.  These  requirements  are 
not  stated  in  physical  terms  but  rather  in  the  logical  terms 
mentioned  earlier.  Ar  example  of  a  physical  requirement  is 
to  provide  a  terminal  or  microcomputer  to  every  person  in 
the  accounting  division.  An  example  of  a  logical  require¬ 
ment  is  to  provide  all  supervisors  in  the  accounting  divi¬ 
sion  query  access  to  the  general  ledger  database  for  report 
generation  and  statistical  analysis.  Because  IC  technology 
is  new,  gaining  popularity,  and  easy  to  relate  to,  the 
tendency  is  to  want  to  rush  to  a  decision  and  select  equip¬ 
ment  and  software  before  the  requirements  are  defined.  This 
should  be  avoided. 

The  uniqueness  of  the  IC,  as  compared  to  other  systems 
development  projects,  requires  that  service  requirements 
also  be  identified.  Determination  of  the  need  for  the  IC  to 
provide  these  services  should  be  reviewed.  Considerations 
may  be  training,  consulting,  programming  support,  applica¬ 
tion  systems  development,  hardware  and  software  procurement 
and  testing,  equipment  maintenance,  configuration  control  of 
hardware  and  software,  vendor  interfacing,  obtaining  group 
discounts,  assistance  in  user  cost/benefit  analyses  and 
;]ustif  ication  studies,  product  demonstrations,  newsletter 
publishings,  supporting  user  groups,  network  control  and 


determine  what  the  IC  can  offer,  before  deciding  what  it 
should  offer.  The  six  options  listed  under  managerial  sup¬ 
port  systems  in  Figure  5  provide  an  excellent  list  of  possi¬ 
ble  user  requirements.  Each  one  of  these  options,  when 
used,  should  be  tied  to  a  specific  function  and  one  or  more 
databases.  The  users  of  each  of  these  combinations  should 
also  be  identified.  These  groupings  can  be  viewed  as  a 
requirements  matrix  of  options,  databases,  and  users.  Any 
of  the  elements  of  this  matrix  may  be  repeated  in  the  forma¬ 
tion  of  these  groupings. 

A  slightly  different  approach  categorizes  requirements 
by  application  size  and  development  time.  Figure  6  provides 
a  list  of  these  categories  in  relation  to  the  overall  view 
of  information  systems.  The  last  three  items  in  Figure  6 
describe  appropriate  uses  of  an  IC  and  provide  a  different 
perspective  for  developing  IC  requirements. 

USER  WAIT 

PATH  AVERAGE  QUEUE 


Traditional  Life  Cycle  (TLC) 

Prototyping 

Purchase  Software 

Small  Systems  Implementation  (IC) 

Ad  Hoc  Requests  (IC) 

Consulting  for  End-User  Computing  (IC) 
Figure  6.  Alternate  Service  Paths 


1 - 2+  years 
6-18  months 

2- 6  months 
1  -2  months 
1 -2  days 

1 -2  hours 

[Ref.  49:  p.  103] 
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other  part  involves  understanding  top  management's  goals  and 
objectives  and  how  these  goals  and  objectives  fit  into  the 
existing  structure.  This  often  requires  not  only  observa¬ 
tion  and  interviews,  but  a  keen  ability  to  sort  out  super¬ 
fluous  and  misleading  information.  System  analysts  and 
outside  consultants  can  provide  unbiased  and  unaffected 
analytical  ability  for  this  endeavor. 

C.  NEW  SYSTEM  REQUIREMENTS 

The  purpose  of  this  activity  is  to  develop  a  description 
and  statement  of  the  new  system  requirements  in  sufficient 
depth  for  user  evaluation  and  approval.  This  usually 
results  in  the  development  of  a  user  requirements  specifica¬ 
tion.  This  document  contains  requirements  that  are  satis¬ 
factory  to  the  user  and  approved  by  the  user.  It  also  is 
common  practice  to  establish  priorities  within  this  document 
because  either  development  costs  may  make  it  impossible  to 
implement  every  request  or  phased  implementation  may  be 
recommended . 

Development  of  systems  requirements  is  a  difficult  task 
because  the  IC  concept  is  relatively  new,  the  technology  in 
support  of  the  IC  is  rapidly  developing,  the  requirements 
are  dependent  on  the  situation  which  can  be  radically  dif¬ 
ferent  from  all  other  situations,  and  the  approach  to  be 
taken  in  this  endeavor  is  unclear  and  often  untried.  As  a 
starting  point,  reexamination  of  Figure  5  can  help  to 


assimilation  ot  technoloQv.  These  stages  ha'/e  broad  appli¬ 
cation  to  most  organizations  or  corporations  regar.dless  of 
other  differences.  The  stage  hypothesis  also  explains  some 
of  the  anomalies  observed  in  the  orderly  growth  of  computer 
technology.  In  an  article  in  EDP  Analyzer  [Ref.  43:  p.  6], 
the  following  synopsis  succinctly  addresses  this  issue: 

Nolan's  and  Gibson's  landmark  1974  paper  [Ref.  44: 
pp ,  76-88]  observed  that  many  organizations  go  througn 
four  stages  in  the  introduction  and  assimilation  of  new 
technology.  These  are:  Introduction,  proliferation,  con¬ 
trol,  and  mature  usage.  During  the  proliferation  stage, 
the  idea  catches  on  and  spreais  'like  wild  fire,'  until 
costs  clearly  get  out  of  hand.  In  the  third  stage,  con¬ 
trol  IS  exercised  in  order  to  contain  the  growth  of  costs. 
Finally,  mature  usage  occurs  in  the  fourth  stage.  An 
organization  can  be  in  several  stages  simultaneously,  for 
different  forms  of  technology. 

McKenney  and  McFarlan  (Refs.  43:  pp.  109-119,  46: 
pp.  145-156,  47:  pp.  36-40,  70-73]  discuss  a  somewhat 
modified  version  of  the  four  stages  (or  'phases,'  as  these 
authors  prefer).  Their  four  phases  are:  (1)  identifica¬ 
tion  and  initial  investment,  (2)  experimentation  and 
Learning,  (3)  management  control,  and  (4)  widespread  tech¬ 
nology  transfer.  This  version  of  the  four  phases  has  the 
advantage,  we  believe,  of  casting  the  important  second 
phase  in  a  somewhat  different  light  from  Nolan  and  Gibson. 
Nolan  and  Gibson  gave  a  negative  name- -pro  1 1 f era tion - - to 
this  phrase,  leaving  the  impression  that  users  are  being 
almost  irresponsible  by  adopting  the  new  technology  too 
rapidly.  McKenney  and  McFarlan  point  out  that  this  is  the 
stage  when  experimenting  and  learning  take  place--a  trial 
and  error  phase.  If  too  much  control  is  exerted  too  soon, 
important  new  uses  of  the  technology  can  be  killed  off. 
[Ref.  48:  p .  6  ] 

The  concept  of  phased  assimilation  of  technology  is  not  only 
useful  in  understanding  the  existing  system,  but  will  also 
be  a  consideration  in  other  segments  of  the  SDLC. 

Understanding  the  user  and  technology  is  only  part  of 
the  work  invol'/ed  with  reviewing  the  existing  system.  The 
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view  can  oe  of  assistance  in  arriving  at  the  logical  view, 

1^  should  not  be  confused  with  the  logical  view,  even  though 
the  log  1 ca 1  - phys ica 1  boundaries  may  not  be  well  defined. 
Also,  neither  view  should  be  substituted  for  the  other. 

The  existing  system  review  should  be  a  more  detailed 
review  of  the  analysis  already  conducted .  This  review 
snould  entail  a  review  of  available  data,  organizational 
climate,  organizational  placement  of  information  systems, 
work  station  (terminal  or  microcomputer)  employment  and 
deployment,  user  and  management  satisfaction,  existing  poli¬ 
cies  and  their  effect,  information  constraints,  existing 
information  system  strengths  and  weaknesses,  report  genera¬ 
tion,  existing  technological  capabilities  (e.g.  graphics, 
electronic  mail,  networks,  fourth  generation  software, 
etc.),  the  degree  of  acceptance  of  information  technoj.ogy, 


the  growth  position  of  the  corporation  or  organization,  the 
personnel  situation  (competency,  morale,  interest,  etc.), 
and  any  other  aspect  or  item  that  could  be  of  assistance  in 
determination  of  the  logical  view  of  the  existing  informa¬ 
tion  system. 

This  information  is  highly  situation  dependent  and  will 
vary  greatly  from  one  organization  or  corporation  to  anoth¬ 
er.  One  concept  that  does  not  seem  to  change  in  this  envi¬ 
ronment  is  the  experience  of  the  organization  or  corporation 
in  the  assimilation  of  new  technology.  There  has  been 


considerable  discussion  and  writing  on  the  stages  of 


IV.  ANALYSIS  AND  GENERAL  DESIGN  PHASE 


A.  PURPOSE  OF  ANALYSIS  AND  GENERAL  DESIGN  PHASE 

The  purpose  of  the  analysis  and  general  design  phase  is 
to  develop  a  more  detailed  understanding  of  the  existing 
system,  to  establish  a  general  design  of  the  new  system,  to 
secure  management  and  user  approval,  and  to  develop  a  plan 
for  the  next  phase,  detailed  design  and  testing  [Ref.  42: 
p.  238].  The  analysis  and  general  design  phase  consists  of 
a  review  of  the  existing  system  and  development  of  new 
system  requirements,  new  system  design,  and  a  plan  for 
detailed  design  and  testing.  Formation  of  the  IC  staff 
should  begin  during  this  phase  so  that  staff  personnel  may 
assist  with  the  SDLC  study,  help  guide  the  IC's  development, 
and  to  plan  for  their  new  roles.  The  IC  staff  should  be 
advised,  however,  that  it  is  possible  that  they  will  be 
required  to  return  to  their  former  positions  should  approval 
for  implementation  be  denied. 

B.  EXISTING  SYSTEM  REVIEW 

The  purpose  for  reviewing  the  existing  system  is  to 
build  an  understanding  of  the  business  goals,  objectives, 
and  functions  involved  in  the  application  areas  encompassed 
by  the  project.  Emphasis  is  on  development  of  a  logical 
view  of  these  areas  of  understanding.  Although  the  physical 
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D.  RECOMMENDATION 


The  rinal  requirement  of  the  investigation  phase  is  to 
make  a  general  recommendation.  This  thesis  assumes  that  the 
development  of  an  IC  is  required  and  that  it  is  the  best 
solution.  The  recommendation  should  include  a  general  de¬ 
scription  of  the  intended  IC.  A  projected  budget  and  a 
justification  should  accompany  this  description.  The  next 
phase  of  the  SDLC  requires  a  closer  investigation  of  the  IC 
solution . 
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occupied  by  end  users.  Space  in  the  information  staff's 
offices  is  usually  easier  to  acquire  than  space  in  end- 
user  quarters;  however,  that  makes  the  center  less  acces¬ 
sible  to  users,  requiring  greater  initiative  on  their 
part .  [ Ref .  51 :  p.  19] 

The  services  that  the  IC  will  provide  should  be  identi¬ 
fied  in  the  detailed  design  specification.  The  administra¬ 
tion  of  these  services  should  be  a  function  of  the  next 
phase,  the  installation  and  implementation  phase.  The  fol¬ 
lowing  list  contains  some  of  the  services  often  provided  by 
ICs : 

1.  training  in  the  utilization  of  hardware  and  software 

2.  consultation  on  hardware  and  software  problems 

3.  equipment  maintenance,  repair,  and  acquisition 

4.  vendor  interface  (group  discounts) 

5.  software  and  lardware  configuration  control 

6.  loan  out  of  hardware  and  software 

7.  newsletter  publication 

8.  software,  documentation,  and  publications  library 

9.  users  group  coordination 

10.  product  demonstrations  (hardware  and  software) 

1 1 .  database  extracts 

12.  clearinghouse  for  all  data  processing  requests 
Design  of  the  communications  architecture  mainly  con¬ 
cerns  outlining  the  various  connections  and  methods  of  con¬ 
nection  between  devices.  This  would  include  network  design 
time  share  service,  micro-mainframe  interfaces,  and  office 
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automation  design.  The  placement  of  protocol  converters  and 
the  type  of  protocol  conversion  would  also  be  included. 

Technical  design  also  involves  the  database  configura¬ 
tion.  Conversion  of  files  to  databases,  combining  and  sepa¬ 
rating  of  databases,  design  of  user  access,  location  of 
databases  (both  in  a  hardware  and  software  sense),  creation 
of  database  extracts,  data  integrity,  and  data  security  are 
all  detailed  design  considerations. 

Administration,  controls,  and  management  are  dependent 
on  the  situation.  These  three  categories  contain  miscella¬ 
neous  items  not  already  included.  For  these  reasons,  items 
in  the  three  categories  are  more  obscure  and  sometimes 
difficult  to  place  between  this  phase  and  the  next  phase. 

C,  PERFORMANCE  SPECIFICATION  AND  MEASUREMENT  PLANNING 

Quite  often  the  IC  is  required  to  prove  its  profitabil¬ 
ity.  This  can  only  be  accomplished  if  there  is  some  measure 
of  performance  and  return  on  investment.  Therefore,  it  will 
be  necessary  to  determine  what  items  are  to  be  measured  and 
to  gather  baseline  data  before  the  IC  is  implemented.  If 
the  performance  standard  and  baseline  measurement  have  not 
already  been  established,  they  should  be  established  at  this 
point  in  the  SDLC  study.  This  also  helps  to  identify  any 
additional  design  characteristics  which  may  have  been  over¬ 
looked  or  misunderstood. 
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In  many  cases  there  is  no  requirement  for  the  IC  to 
justify  its  existence.  It  seems  that  many  ICs  have  shown 
such  astronomical  returns  on  investment  that  upper  manage¬ 
ment  is  not  even  interested  in  cost/benefit  studies  or  proof 
of  success.  Most  of  these  types  of  ICs  have  concentrated  on 
the  use  of  microcomputers.  The  following  testimonials  con¬ 
firm  this  situation: 

Even  after  only  two  years,  Signode’s  (Signode  Industries) 
information  center  has  had  no  trouble  continuing  to  justi¬ 
fy  its  existence  to  upper  management.  "We  give  presenta¬ 
tions  to  management  explaining  what  we  are  and  what  we're 
trying  to  do,"  he  (John  Nylen,  IC  supervisor)  says,  "then 
we  bring  in  end  users  to  tell  what  they've  done.  Just 
from  that,  management  can  see  that,  while  it's  often  very 
difficult  to  figure  hard  dollar  savings  on  this  type  of 
program,  it  is  so  successful  and  so  completely  integrated 
into  our  business  that  we  can't  do  without  it,"  he  says. 
"People  need  the  information  they  can  get  with  our  tools 
to  ma)<e  the  decisions  necessary  to  run  their  portion  of 
the  business.  We  are  no  longer  expendable."  [Ref.  52: 
p.  27] 

"I  haven't  had  to  justify  the  information  center  budget, 
amazingly  enough,"  John  Lucas  ( IC  manager  for  Dennison 
Manufacturing  Company)  said.  "I'm  prepared  to  do  it.  The 
return  is  so  obvious  that  they  (management)  haven't  felt 
it  necessary."  [Ref.  53:  p.73] 

A  sampling  of  IC  applications  supports  the  argument  that  a 
solid  business  case  exists  for  their  implementation.  At 
one  company,  ad  hoc  applications  showed  a  productivity 
improvement  factor--def ined  as  the  effort  without  the  IC 
compared  to  that  with  the  IC--ranging  from  threefold  to 
more  than  a  hundredfold.  At  the  same  time,  return  rates 
of  repetitive  applications  ranged  from  50  to  several  thou¬ 
sand  percent.  For  some  of  these  applications,  a  one-time 
use  of  an  application  more  than  paid  for  its  development. 

[  Ref  .  54  :  pp .  18-19] 

"when  we  do  a  cost  justification  for  a  micro  installation, 
we  always  loo)<,  for  a  paybacic  of  not  more  than  three 
years,"  (Karen)  White  (IC  supervisor  for  California  State 
Aiutomobilo  Association)  says,  "but  some  of  our  paybacks 
have  been  more  like  two  to  three  months!"  [Ref.  55:  p.  60] 
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Although  the  above  quotations  illustrate  the  bright  side  of 
IC  justification,  there  is  a  dark  side  as  well.  Managers 
will  sometimes  be  faced  with  expenses  that  were  not  expected 
or  were  larger  than  estimated.  The  following  quotations 
expla i n : 

The  hidden  costs  of  using  personal  computers  don't  really 
involve  unknown,  inexplicable  processes  or  gadgets  either. 
Most  every  hidden  cost  is  a  rather  mundane  and  predictable 
necess ity . . . . For  large  corporations  hidden  personal  com¬ 
puting  costs  could  be  a  six-figure  tab  for  rewiring  and 
construction  work  or  another  big  bill  for  the  cost  of 
replacing  obsolete  computers  with  newer,  more  practical 
systems.  [Ref.  56:  pp.  122-123] 

To  facilitate  installation  of  the  Wangnet  cable  throughout 
the  New  York  Exchange's  buildings,  (Jerry)  Burden  (manager 
of  office  automation  systems  for  the  New  York  Stock 
Exchange)  eventually  had  to  spend  more  than  $500,000. 

"The  component  cable  of  Wangnet  only  cost  about  $20,000," 
he  says.  "The  rest  of  the  money  went  to  architects, 
construction  workers  and  contractors.  Every  time  we 
wanted  to  put  in  cable,  we  had  to  rip  up  parts  of  the 
building  and  draw  up  new  plans  and  pay  for  new  construc¬ 
tion."  [Ref.  57:  p.  127] 

In  the  first  year  of  operation,  a  personal  computer  pur¬ 
chased  for  about  $2500  may  run  up  thousands  of  dollars  in 
additional  costs,  suggests  Richard  Dalton,  the  president 
of  Keep/Track  Systems,  a  San  Francisco  computer  consulting 
firm.... "The  actual  costs  of  operating  a  computer  is 
frightening  for  people  who  expected  their  spending  to  end 
after  their  initial  purchase,"  Dalton  says.  "Sometimes 
people  can't  believe  they  spent  $10,000  for  a  computer  in 
the  first  year.  These  costs  are  pretty  damned  insidious. 
They  creep  up  on  you  without  notice."  [Ref.  58:  p.  123] 

Sneider,  who  is  an  accountant  (for  Laventhal  and  Horwath). 
not  a  data -process ing  expert,  points  out  that  the  purchase 
price  of  an  individual  computer  isn't  great  in  and  of  it¬ 
self,  but  add  a  number  of  them  together  and  you've  got  a 
significant  investment.  Thus  allocation  and  efficient  use 
are  becoming  important.  [Ref.  59:  p.  73] 

Most  organizations  will  use  established  standard  per¬ 
formance  measurements  which  can  b*^  employed  as  is  or  with 
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minor  modifications.  The  difference  with  ICs  is  that  many 
corporations  or  organizations  find  themselves  operating  in 
stage  two  of  technology  assimilation.  If  controls  are  in¬ 
stituted  during  this  stage,  then  interest  is  stifled  and  end 
user  computing  will  most  likely  stall.  This  concept  is 
treated  well  in  the  following  quotation: 

Since  it  (end  user  computing)  is  a  relatively  new  area, 
past  practices  may  not  meet  the  needs.  A  key  point  seems 
to  be:  Recognize  that  phase  two  in  end  user  computing  is 
a  period  of  experimentation  and  learning,  and  is  not  the 
time  to  be  exerting  tight  controls.  The  basic  decision  of 
whether  (and  how  much)  to  encourage  versus  constrain  end 
user  computing  clearly  should  be  made  by  executive  manage¬ 
ment,  and  this  decision  will  affect  the  plans  on  how  to 
support  end  user  computing.  Hopefully,  executive  manage¬ 
ment  will  come  to  appreciate  the  nuances  of  the  issues 
involved.  [Ref.  60:  p.  12] 

A  solution  used  by  some  organizations  is  to  treat  end  user 
computing  like  a  research  and  development  project  where 
temporary  losses  are  accepted  because  the  end  result  may  be 
high  yield  on  investment. 

D.  STAFFING 

Staffing  is  one  of  the  most  critical  issues  for  the 
success  of  the  IC  concept.  Although  some  staff  positions 
will  have  been  filled  already,  consideration  of  the  other 
staff  positions  is  necessary.  At  a  minimum  there  should  be 
an  IC  manager.  The  IC  manager  should  be  tasked  with  respon¬ 
sibilities  commensurate  with  the  design  of  the  IC.  Usually, 
he  has  overall  responsibility.  John  Seymour,  president  of 
Information  Center  Sciences.  Incorporated  (a  consulting 


firm)  writes  the  following  about  the  1C  manager's  responsi¬ 
bilities: 

The  manager  of  this  function  (the  IC)  has  got  to  under¬ 
stand  the  scope  of  the  problems,  the  financial  and  system 
impacts  of  the  marriage  of  two  worlds.  He  or  she  has  to 
see  where  controls  are  necessary  and  where  they  stifle 
objectives.  While  apparently  serving  the  needs  of  per¬ 
sonal  computer  users,  the  manager  must  be  in  touch  with 
the  large-scale  issues:  communications,  data  access,  se¬ 
curity,  support,  and  much  more.  [Ref.  61:  p.  31] 

If  the  IC  is  designed  as  a  profit  center,  this  authority  may 
be  quite  extensive.  On  the  other  hand,  if  the  IC  manager 
gets  strong  guidance  from  a  steering  committee  then  his 
decision  making  authority  will  be  minimal.  Use  of  a  steer¬ 
ing  committee  as  a  controlling  force  should  be  considered 
during  this  phase.  The  makeup  of  that  committee  should  also 
be  determined.  One  type  of  committee  composition  puts  the 
users  in  charge.  The  following  is  an  example  of  such  an 
instal la  tion : 

"At  Gulf  (Research  and  Development  Corporation),  the  [in¬ 
formation  center]  is  split  between  the  central  staff  and 
respective  user  areas,"  Sam  Defazio  noted.  "Through  a 
steering  committee,  the  beneficiaries  of  the  technology 
really  'own'  the  information  center  while  Systems  Develop¬ 
ment  provides  day-to-day  operations,"  he  said.  [Ref.  62: 
p.  131] 

Steering  committees  may  be  chaired  by  top  management,  some¬ 
one  from  the  data  processing  department,  someone  from  the 
management  information  department,  user  personnel,  the  IC 
manager,  or  other  IC  staff  members.  Major  decision  authori¬ 
ty  should  also  be  decided  and  delineated  before  implementa¬ 
tion.  Other  IC  positions  may  include  trainer,  consultant. 
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systems  analyst,  secretary,  administrative  assistant,  pub¬ 
lisher,  and  purchasing  agent.  Quite  often  staff  members 
will  be  tasked  witn  the  responsibilities  of  two  or  more  of 
these  positions  as  indicated  in  the  following  quotation: 

Each  member  of  the  CSC  team  ( IC  staff),  including  the 
leader,  or  coordinator,  supports  one  or  more  tools  and 
provides  backup  in  others.  The  secretary  also  gets  in¬ 
volved  by  teaching  word  processing  and  answering  technical 
questions  about  several  of  the  tools.  [Ref.  63:  138] 

The  selection  and  recruitment  of  personnel,  however,  is  a 

function  of  the  next  phase. 

The  IC  staff  must  interface  with  all  types  of  people 

with  varying  degrees  of  interest  and  varying  abilities.  A 

common  theme  throughout  the  current  literature  is  that  the 

staff  members  need  to  have  training  and  consulting  skills 

more  than  they  do  computer  skills.  The  idea  is  that  it  is 

easier  to  train  a  skilled  teacher  about  computers  than  it  is 

to  train  a  computer  expert  about  teaching  and  customer 

rapport.  The  design  of  ICs  must  reflect  not  only  this  fact 

but  the  following  fact  as  well: 

Needless  to  say,  qualified  candidates  for  the  CSC  team  ( IC 
staff)  are  scarce.  Because  of  their  excellent  qualifica¬ 
tions  and  the  diverse  experience  gained  from  being  part  of 
the  CSC  team  { IC  staff),  these  people  are  highly  marketa¬ 
ble  to  other  organizations.  Consequently,  the  CSC  (IC) 
has  seen  extensive  staff  turnover.  Four  people  from  the 
team  have  moved  on  to  other  assignments  in  less  than  two 
years.  Consider  the  impact  of  a  75%  or  100%  turnover  in  a 
high  performance  team  and  how  to  manage  for  it.  [Ref.  64: 
p.  140] 

Cne  concept  that  may  help  the  situation  described  above 
IS  that  of  providing  a  career  path  for  IC  staff.  While  some 
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publications  claim  that  the  IC  is  a  dead-end  position, 
others  claim  it  is  an  excellent  place  to  get  exposure  to 
other  people  in  the  organization  and  can  be  a  stepping  stone 
to  a  better  position  in  the  corporation  or  organization. 

That  notwithstanding,  Daniel  Couger,  a  professor  of  computer 
management  at  the  University  of  Colorado  College  of 
Business,  has  outlined  a  career  path  for  computer  pro¬ 
fessionals  that  shows  how  the  IC  staff  can  progress  in  an 
organization.  This  career  path  is  reproduced  in  Figure  7 
[Ref.  65:  p.  109].  In  it  he  shows  where  the  IC  supervisor 
can  become  the  information  systems  manager  or  can  become  a 
user  manager . 

E.  PROTOTYPING  AND  SYSTEM  TESTING 

The  purpose  of  prototyping  and  system  testing  is  to 
ensure  that  what  has  been  planned  will  work  and  to  provide 
an  opportunity  to  make  any  last  minute  changes  before  imple¬ 
mentation.  This  is  important.  An  article  from  Datamation 
magazine  supports  this  statement  in  the  following  quotation: 

This  (advice  comes)  from  an  IBMer  who  has  been  involved 
with  some  big  (information)  centers  in  California:  "Make 
sure  all  the  (information)  center's  major  start  up  prob¬ 
lems  are  ironed  out  before  the  user  ever  walks  through  the 
door.  If  the  user  senses  the  (information)  center  still 
has  problems,  it  will  add  to  his  apprehension  and  may 
cause  him  to  bolt  and  run."  [Ref.  66:  p.  32] 

There  is  more  than  one  way  to  ensure  the  smooth  opera¬ 
tion  of  the  IC  before  implementation.  One  method  is  to  not 
do  anymore  than  a  paper  review.  Although  this  is  not 
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usually  recommended,  in  some  cases  it  is  appropriate.  The 
most  common  case  is  for  the  simple  IC  that  provides  minimal 
service.  A  more  normal  situation  requires  some  degree  of 
testing.  In  a  more  universal  view  of  the  IC,  John  P.  Murray 
writes:  "The  development  of  the  information  center  process 

IS  an  evolutionary  process  that,  in  order  to  be  most  effec¬ 
tive,  should  be  done  in  phases,"  [Ref.  67:  p,  37]  The  first 
phase  is  the  prototyping  or  testing  phase. 

Although  prototyping  is  the  method  most  often  mentioned 
in  the  literature,  there  are  other  methods  to  test  the 
operation  of  the  IC.  In  reality,  these  other  methods  are 
either  partial  implementations  of  a  prototype  IC  or  they  are 
full  implementations  of  a  partial  prototype.  Therefore, 
only  the  full  prototype  method  will  be  discussed  in  this 
thes  is  . 

Testing  an  IC  prototype  is  the  same  thing  as  conducting 
an  IC  pilot  study.  There  have  been  a  sufficient  number  of 
IC  pilot  studies  conducted  to  provide  some  insight  into  how 
they  should  be  conducted.  John  Mele,  product  support  spe¬ 
cialist  at  K-Mart  Apparel  Corporation,  has  been  paraphrased 
as  having  said  the  following: 

A  pilot  project  for  the  fledgling  information  center 
should  be  identified,  he  said.  Ideally,  the  project 
should  be  in  an  area  in  which  automation  can  provide 
tangible  and  measurable  benefits.  Look  for  a  department 
that  is  swamped  with  work,  has  mostly  manual  systems  in 
place  and  is  receptive  to  the  idea  of  computerization. 

Too  many  promises  should  not  be  offered  at  the  outset,  he 
stressed.  [Ref.  68:  p.  23] 
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Another  article  by  Steve  Hearn,  manager  of  management  sup¬ 
port  services  for  ARCO  Petroleum  Products  Company,  gives  his 
estimate  of  the  length  of  time  needed  for  the  pilot  study: 

The  length  of  the  pilot  varies,  depending  of  the 
preparation  needed  to  begin  support  of  the  firsc  user. 

Once  the  first  user  is  trained,  approximately  three  month's 
should  be  sufficient  to  assess  whether  a  long-term 
commitment  should  be  made  to  the  IC  concept.  [Ref.  69: 
p.  221 

Because  the  IC  concept  is  so  unusual,  the  steps  required 

to  implement  a  pilot  study  may  not  be  intuitively  obvious. 

For  this  reason,  the  following  quoted  material  has  been 

taken  from  an  article  by  Marsha  Seidman,  president  of  Crwth 

Computer  Coursewares  [Ref.  70:  p.  9]: 

A  successful  pilot  is  usually  the  direct  result  of  careful 
planning,  involving  the  systems  resources  as  well  as 
knowledgeable  product  consultants.  Several  pilots  have 
failed  because  of  slow  response  time  or  lack  of  terminals. 
In  one  case,  a  lack  of  DASD  (Direct  Access  Storage  Device) 
space  prohibited  the  installation  of  a  fourth  generation 
language.  Here  are  the  steps  for  implementing  a  pilot: 

1.  Plan  your  system  resources  in  advance:  terminals, 

DASD  space,  CPU  use,  user  IDs. 

2.  Select  a  user  department  committed  to  the  concept  of 
end  user  computing. 

I.  Choose  a  small  group  of  highly  motivated  business 
professionals  from  the  department. 

4.  Select  a  fourth  generation  language. 

.  Tram  an  information  center  consultant  as  a  product 
specialist . 

'j  .  [’rain  the  business  professionals  in  the  use  of  ttie 
la  nguaqe . 


Df’fine  ob]ectives  and  the  range  of  acceptance  criteria 
thrit  will  determine  the  success  of  your  pi  1  it  . 
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After  the  pilot  study  has  proven  to  be  a  success,  the 
usual  admonitions  apply.  Be  careful  to  not  overextend  the 
resources  or  the  abilities  of  the  IC  staff  or  of  the  in¬ 
stalled  hardware  and  software.  Also  be  reasonably  sure  that 
the  success  of  the  IC  can  be  duplicated  in  the  full  system 
environment.  There  would  be  nothing  more  embarrassing  than 
to  realize  that  the  reason  the  pilot  was  a  success  was  due 
to  special  circumstances  and  extra  attention  and  that  the 
production  IC  is  a  failure.  It  also  might  prove  very  costly 
to  make  such  a  mistake. 

F.  GENERAL  IMPLEMENTATION  PLANNING 

In  keeping  with  the  SDLC  methodology,  the  end  of  this 
phase  is  in  reality  the  precursor  to  the  next  phase,  the 
installation  and  implementation  phase.  Even  before  the 
pilot  study  is  complete,  a  general  plan  for  the  next  phase 
should  be  developed.  This  plan  should  cover  general  items 
that  will  need  to  be  instituted.  The  benefit  of  this  activ¬ 
ity  is  that  it  provides  the  opportunity  to  identify  actions 
that  must  be  instituted  before  this  phase  ends  and  allows 
for  a  better  transition  from  pilot  study  to  full  operation. 

Additional  equipment,  hardware,  software,  documentation, 
and  supplies  should  be  identified.  Likewise,  additional 
procedures  and  policies  should  be  disseminated.  Finally, 
loro'iral  spreading  of  the  word  and  mass  education  of 
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potential  users  should  be  considered  so  as  to  avoid  any  more 
complications  than  absolutely  necessary. 
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VI.  INSTALLATION  AND  IMPLEiMENTATION  PHASE 


A.  PURPOSE  OF  INSTALLATION  AND  IMPLEMENTATION  PHASE 

The  purpose  of  the  installation  and  implementation  phase 
IS  to  transit  from  the  present  system  to  the  new  system  and 
to  get  the  new  system  functioning  as  a  productive  and  suc¬ 
cessful  entity.  This  phase  results  in  the  most  detailed 
breakdown  of  the  areas  dealt  with  in  the  previous  phases. 

If  a  pilot  study  was  conducted,  this  phase  puts  into  prac¬ 
tice  the  lessons  learned  from  that  study.  It  is  recommended 
that  this  phase  follow  the  concepts  presented  earlier,  espe¬ 
cially  that  of  incremental  implementation. 

It  would  be  virtually  impossible  to  enumerate  all  of  the 
considerations  that  should  be  mentioned  in  this  phase  of  the 
IC  implementation.  Also,  due  to  the  nature  of  the  SDLC 
study,  most  cf  the  ma^or  items  have  already  been  covered. 
Therefore,  this  chapter  will  concentrate  more  on  the  unu¬ 
sual,  innovative,  and  important  detailed  items  that  contrib¬ 
ute  to  a  successful  transition  and  implementa o ion .  These 
Items  are  categorized  in  an  attempt  to  provide  a  logical 
approach  for  a  more  complete  installation  and  implementa¬ 
tion.  For  an  IC,  installation  refers  to  puttinq;  the  equip¬ 
ment  ind  software  in  place.  The  manager  tasked  with  this 
responsibility  is  assumed  to  have  the  necessary  skills  to 

IC  implementation,  however,  requires 
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tccornplish  this  job. 


:j  ’-'t.-;:  ir  duSi  di'\  instructor  is  free.  Vi'ditinq  time  to 

•  t  _i  class  IS  t\’pical]y  Ja.;-ss  than  tv;o  wtic-Ks  .  [kef.  10s; 

!  ■  ;ccs  uss-rs  from  (Grace  Incorpiorated  '  s  )  marketing  went 

cicK  o  tn-iir  department  after  learning  the  basics  of  the 
.  /St--:',:  jnd  immediately  showed  other  department  members  how 

•  .icc'.-ss  and  use  the  applications  they  had  built  soon 

tnc  (three  day)  training  session.  In  a  matter  of 
memners  of  marketing  were  utilizing  the  information 
■:'i  r  s-arcice.  i  P.ef  .  106:  p.  27] 

rormative  stcjac-  of  an  information  center,"  says 
!•- enmoi  r  andia  :  1  ,  president,  Cornshare,  Inc.,  .hnn  Arbor, 

,  "it  IS  roasibl-c  to  handle  the  user  training  needs  with 
C1-.  or  a  lew  instructors,"  using  traditional  classroom 
1  ;  a  1  n  1  .na  ,  however,  th.is  method  becomes  impractical  as  two 
m  :  ■  s  r  j’.-'.'e  I'Opment  s  occur.  first,  larger  numbers  of  end 
.;s-.  rs  'eguire  training  in  even  larger  numbers  of  software 
products ....( Second )  There  are  more  "occasional"  computer 
.iS’-'’'s  who  require  refres'icr  courses  at  least  once  a  year. 


S  1  1  I  (so  C'u.sot  i.I  I.'-jL) 

.'liny  TC  staff  in.o  issues  are  commonly  found  in  any  staff- 
ition.  Examples  or  these  issues  are  the  hiring  of 
:'a:y  n-:- 1  n  ,  niring  from  inside  the  organization  or  from 
:  !•',  ur.:;  i-.d  erm  na  t  i  on  of  skills  required.  There  are, 

\  -  r  i.'uc  1  r  ement  s  that  are  peculiar  to  the  IC. 

•■  it  ti.'c  staff  '■'•reds  to  have  patience,  good  "tube- 
"  :-i -i  n”,--‘ r  ,  i:r:i  shoi.ild  be  interested  in  end  results  rather 
'  n-  r  • 'C  ni'.o  1 0'uy  tde-t  achi-rves  it  [Ref.  10S:  p.  28]. 

■  i  r  V' r  t  a  r;  t  ’part  of  IC  staffing  rei’olves  around  the 
. ^  1  r;  r  ^  .  T  C  c;  n  .s  u  1 1  an  t  s  are  the  main  interface  between 
,-o  '  c  in  1  1C.  In-ry  n-rea  to  be-  placed  near  the  end 


ror’ 'v't;  r  s  I  on  s  -ind  a  nia  1  t  ipl  ici  ty  of  human  interfaces,  the 
-;nd-user  i  I  i  not  toiorate  such  an  unfriendly  environment, 
tsuaily,  the  first  tool  learned  will  be  the  tool  that  the 
user  Alii  want  to  stick  with,  and  with  which  he  will  wish 
to  rriOi-t  his  needs.  .  .  .Information  Centers  that  I  have  come 
across  that  have  tried  replacing  several  tools  with  fewer 
multi-purpose  products,  have  found  it  difficult  to  wean 
tno.r  customers  from  the  old  tools,  and  the  proliferation 
IS  compounded.  [Ref.  102:  pp .  28-29] 

hr.  Seynicur  provides  a  "pseudo"  solution  to  the  problem  of 
erid  users  from  the  software  packages  already  in 
aco,  oy  the  following  method: 

don't  try  (to  wean  end  users).  Make  the  end  users  learn 
.it  least  two  of  the  spreadsheets  available,  or  two  of  the 
wrd  p*rocessors  for  starters.  They  may  not  want  to  use 
rv.'tn,  but  the  benefits  are  still  positive.  First,  you  get 
ureater  back-up,  transferability  of  skills,  and  compati¬ 
bility  of  Knowledge.  Second,  the  users  by  learning  ]ust 
one  other  package,  broaden  their  overall  capability  and 
unuerstandinq  enormously.  [Ref.  10.1:  p.  38] 

Sharina  the  experiences  of  others  is  a  pov;erfui  educa- 

o.n  tool.  With  this  thought  in  mind,  four  quotations 

1-ite  interesting  training  experiences  of  others: 

1:0  y  (Inland  Steel's  IC)  discoverei,  howex’er  ,  that  day-to- 
du’.  probiens  demanded  time  froci  the  !  i  nf  C)rma  1 1  on  i  center 
staff,  and  turned  to  compu t e r - oa sed  trainina  to  clear 
star:  for  support  to  users ....  Now  tney  (Inland  Steel)  have 
uppcinted  one  end  user  in  each  department  to  be  a  "user 
s::)OC  1  a  1  1  St  ,  "  who  gets  advanced  training  and  then  supports 
oetween  eight  and  15  users  in  that  department.  [Ref.  104: 
o .  16] 

l'raini:ic  (at  Eiixon  Corporation)  is  geared  to  clients' 
soruidulos.  Courses  are  also  designed  to  n  i  ve  a  working 
K ;  [r.  of  tools  wlthout  turning  clients  into  technical 

•s Pi? r s  .  Each  course  maximizes  hands-on  student  exercises 
.i:,  :  1  n  ■  H'.  1  :■ 'O  o  .lecture  sessions,  and  no  course  is  lonoer 
t’li:.  cu-  b:  y.  Each  class  is  limited  tc  fo.ir  p-.'Ople,  and 
:.  ;  /i.'nt‘=.  with  seniority,  c-asses  at'.,-  a  ■•.'■i :  1  a  t '  1  e  i 

;  ''iv-  t'-'is  p.o  ri'ibl  '  s'.*’  i  cl  ■ 

'  •  vc'  '  *■  3 I  ''’.t  nc.'!'*"  c  1  1  or.”  '.■■‘cc 


towar^is  training  users  that  may  be  helpful  in  the  selection 
of  t nt  proper  training  method  IRef.  100:  pp.  13-14]; 

1  .  Users  are  intelligent. 

Users  have  never  used  a  computer  before. 

Users  are  interested,  but  impatient. 

4.  Users  have  a  sense  of  humor. 

:  .  lisers  will  mane  mistakes. 

r.  Users  need  to  understand  some  DP  terms. 

Users  need  to  know  when  to  use  a  computer  and  when  not 

t  use  one. 

Users  need  to  know  about  security  and  backup. 

.  Users  need  to  know  computing  costs. 

End  user  training  is  not  without  its  problems.  One  of 
til--  most  difficult  problems  to  solve  is  how  to  satisfy  the 
•inu  user  thiat  has  no  patience.  "'End  users  want  to  be  able 
lea.rn  -inouuh  to  get  up  and  going  on  their  own  proiects  in 
u.t',  ,  a  Uciit-duv  if  they  can.  And  most  would  like  to  be 

learr;  it  all  in  30  minutes,'  observes  (Bob)  Richter 
(  :  ■  .•  i.  :.s  1  t  a  nt  and  trainer  for  Deltak,  Inc.)."  [Ref.  101: 

:  .  ■  :  An. ut.nt;-!'  problem  concerns  the  user's  capacity  and 

;•  .  '..  am  .different  software  packages.  .Merlyn  Vaughn, 

r :  i  i.,' nt  an:  aeneral  manager  of  Systems  Software 

:  .  .  r  :  u.  '•  talker  Interactive  Products,  capsuiizes  this 

!'  Ur  1 "  v  an  luid  user  to  learn  several  differ- 

■  ‘  r'---.-t  'n :  s  basic  information  management 

;  ■  ;  1  .  r,].  !!  m'-f.'ssior.als  ".innt  be  used  to  freiuent 
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personality  problems  of  one-on-one  training. 


there  are  some  reasons  for  not  using  CBTs .  One  is  that  they 

carmot  replace  the  human  touch.  But,  until  ]ust  recently, 

tinty  had  not  been  of  very  good  quality'.  Gary  DeV.'ard  Brown, 

•.'XoCLitive  t’lce  president  of  Crwth  Computer  Coursev;a  r  es  ,  a 

C’h  I  \’ondor  ,  gives  some  guidance  in  this  area: 

Combining  instruction  with  hands-on  experience,  CBT  is 
potentially  the  ideal  vehicle  for  teaching  end  users  coni- 
pjter  skills.  However,  gust  because  a  course  is  presented 
through  CBT  does  not  guarantee  effectiveness.  The  quality 
of  a  CBl'  course  for  end  users  will  depend  on  the  following 
tnree  points  [Ref.  97:  p.  10]: 

does  the  course  address  the  target  audience? 

Is  the  subgect  matter  well  presented? 

Are  the  strengths  of  the  medium  fully  exploited? 

/:  course,  CBTs  are  more  complicated  than  is  suggested.  The 
only  sure  way  to  ensure  that  a  CBT  meets  the  IC's  needs  is 
to  use  the  CBT  and  form  a  judgment  based  on  preference, 
hnero  are  two  additional  items  worth  mentioning  when  trying 
t:'  evaluate  a  CBT.  The  first  is  the  ratio  of  question 
scraeris  to  text  screens.  The  current  thought  is  that  ideal- 
1 the  user  would  line  to  see  a  1:1  ratio  [Ref.  96:  p.  15). 
li.e  Second  Item  is  that  a  workbook  can  be  a  valuable  asset 
t,.  ne  casual  user  [Kef.  99:  p.  32]. 

In  creatina  CBTs  for  novice  users,  Gary  DeWard  Brown 
•  S'js  some  assumptions  about  users  that  helps  his  company  to 
ieu’.'bop  a  aood  product.  These  assumptions  are  paraphrased 
tollc'wina  list  because  they  give  a  perspective 


trainino  pacKaqe  to  meet  the  specific  needs  of  the 
organization.  Other  CBT  packages  aro-  unalterable. 

CEiT  is  often  the  preferred  method  for  training  because 
of  its  centralized  distribution,  administration,  and  moni¬ 
toring  capabilities: 

It  (CBT)  easily  accommodates  changes  in  course  material. 

It  allows  trainee  performance  to  be  centrally  monitored 
and  administrative  records  to  be  automatically  updated. 

And  it  permits  a  high  degree  of  interaction  between  stu¬ 
dent  and  system,  according  to  Christopher  Howey,  a  pro¬ 
fessor  of  instruction  and  training  technology  at  Governors 
State  University  in  Park  Forest,  Ill.... it  (CBT)  lends 
Itself  well  to  large  user  organizations  that  have  to 
disperse  their  instructional  material  to  many  employees 
over  a  wide  geographic  area,  (Gary)  Brown  (vice-president 
of  CRWTH  Computer  Coursewares,  Inc.)  said.  (Ref.  95: 
p.  13] 

...users  can  reportedly  transmit  CBT  course  material  back 
and  forth  betvieen  their  central  and  remote  computing  in¬ 
stallations.  From  a  user's  standpoint,  the  advantage  of 
having  such  an  uploading  and  downloading  capability  is 
that  It  provides  a  "centralized  means  of  managing  instruc¬ 
tional  resources,"  according  to  professor  Chri st opher 
iiowey  of  Governors  State  University  in  Park  Forest,  III. 
"Large  organizations  need  to  be  able  to  centrally  store 
results  so  they  can  decide  which  employees  are  qualified 
to  receii'e  a  particular  type  of  training  and  which 
a r en ' t . "  .  .  .  In  addition,  CBT  development  tools  may  soon 
;iairi  the  ability  to  upload  personal  comput er -generated 
courseware  to  a  large-scale  CPU,  where  the  material  would 
reside  centrally  as  a  "data  file  in  a  data  base  management 
system  1  DBMS ]  , ”  (Gloria)  Gery  (vice-president)  of  the 
Courseware  Developers,  Inc.,  in  Manchester,  Conn. )  pre- 
dir-ted.  If  a  stored  lesson  later  required  revisions,  the 
owner  would  need  merely  to  rewrite  its  one  mainframe- 
resident  copy  and  then  could  immediately  distribute  up¬ 
dated  versions  of  the  courseware  to  all  remote  end  users. 
[Ret.  96:  p .  22] 

'"MTs  can  save  money  by  teaching  users  without  requiring 
*  h.e  s.?r\-ices  of  a  staff  trainei  .  They  are  also  more  indi- 
v  :  ! a  1  '  s  t ;  c  that  trie  classroom  environment  and  elim,  inate  the 


discussed  in  any  detail,  any  one  of  these  training  options 
may  be  appropriate  under  the  right  circumstances  [Ref.  93: 
p .  2  4): 

1 .  Formal  classroom 

2.  One-on-one  tutoring 

3.  Computer-based 

4.  Videotape-based 

5.  Interactive  video  disk 

6.  Inaependent  study 

/'  .  Contractors 

The  one  training  option  that  will  be  discussed  is  option 
nurnoer  3,  computer-based  training  ( CBT )  .  This  option  seems 
to  meet  more  of  the  IC  needs  than  any  other.  It  is  more 
effective  tnan  other  methods,  lends  itself  well  to  large 
user  organ  1 t ions ,  and  has  a  strong  capacity  for  simulation 
.  Kvd  .  "<4:  p.l£].  CBT  allows  the  user  to  become  familiar 
V.  ;  •  :  a  software  package  by  working  through  an  interactive 
SC' ft  ware  program.  This  program  will  not  only  feature  the 
r'.  1  nd  of  knowledge  required  to  use  a  software  package,  but  it 
will  often  be  composed  within  the  package  it  is  designed  to 
teach.  It  will  often  hand-walk  the  user  through  the  package 
on  the  actual  system  that  the  user  will  be  using.  Most 
initial  CBT  packages  were  designed  for  mainframe  end  user 
computinci,  but  more  are  becoming  available  for 
"  :i  cr 'O'omp'.iters  as  well.  Some  CBTs  ,  called  authoring  sys- 
•■u's,  allow  the  oraanization  to  develop  and  modify  the 
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The  types  et  training  are  expressed  by  the  following 
quotat ion: 

We  see  end  users  needing  five  types  of  training:  (1)  data 

processing  concepts,  (2)  quick  start,  (3)  refresher  aids, 

(4)  help  in  overcoming  difficulties  of  advanced  use,  and 

(5)  explanation  of  the  assumptions  behind  the  models  they 
plan  to  use.  [Ref.  90:  p.  4] 

These  categories  of  end  users  and  types  of  training  offer 
both  a  method  for  understanding  the  training  problem  and  a 
framework  within  which  to  operate.  Use  of  these  categories 
IS  left  up  to  the  reader. 

Training  is  expensive.  This  point  is  clearly  presented 

in  the  following  two  quotations: 

To  get  a  good  trainer  these  days,  you  may  have  to  spend 
quite  a  bit.  For  an  in-house  person  salaries  have  risen 
steadily  in  recent  year s - - $ 2 4 , 300  (1  979),  $27,200  (1  980), 
$29,300  (1981),  to  $31,900  (1982)--and  probably  continue 
to  climb.  But  far  more  expensive  than  in-house  training 
IS  an  outside  consultant,  whose  rates  will  range  anywhere 
from  $100  a  day  to  $2,000  an  hour.  In  short,  training  can 
be  expensive,  though  perhaps  not  as  expensive  as  the 
ignorance  it  can  replace.  [Ref.  91:  p.  56] 

Ferrin  (Corporation)  has  found  that  it  can  take  anywhere 
from  20  to  100  hours  for  a  person  to  get  up  to  scratch  on 
the  basic  operation  of  a  single  pc  program,  like  a  spread¬ 
sheet  or  database  package.  The  company  figures  that  the 
average  cost  to  a  corporation  is  $40  per  hour  per  student, 
and  the  total  learning  cost  can  reach  $800  to  $4,000  for  a 
single  corporate  pc  user.  There's  also  the  added  cost  of 
the  other  people  that  get  involved  in  helping  users,  such 
as  department  colleagues,  in-house  computer  professionals, 
and  outside  organizations  like  Ferrin  (a  pc  services 
firm).  Ferrin  calculates  that  additions  like  these  can  up 
the  total  learning  cost  to  between  $1,000  and  $6,000  per 
user.  And  that's  gust  for  one  package.  [Ref.  92:  p.  135] 

Faced  with  expenses  of  this  magnitude,  one  cannot  help 

out  wonoer  what  are  the  training  options.  Although  only  one 

f  tne  options  mentioned  in  the  followinq  list  will  be 


Sb  million  (Kot.  8b:  p.  94).  Althounh  in  this  case,  the 
error  was  cauyht  early  enough  not  to  cause  any  problem,  the 
conse'ouences  cculd  have  been  disastrous. 

tser  training  is  also  important  because  of  the  advan- 
taaes  it  offers.  One  article  claims  "that  users  need  sixty 
t'-'  eighty  hours  'to  figure  out  the  computer  on  their  own.'" 

1  Ref .  86:  p.  64)  The  same  article  states  that  this  training 
can  be  accomplished  in  twenty  hours  through  a  commercial 
training  workshop  (Ref.  87:  p.  64). 

An  even  more  sobering  tliought  ,  is  that  users  can  not  do 
it  on  their  own.  "Once  new  users  are  left  alone  with  their 
computers,  even  the  simplest  questions  can  become  ma^or 
obstacles."  [Ref.  88:  p.  236]  Therefore,  not  only  is  train¬ 
ing  important,  but  follov;-on  training  support  is  3ust  as 
important. 

Ail  end  users  do  not  need  comprehensive  training.  It  is 
important  to  identify  the  types  of  end  users  and  to  under¬ 
stand  the  different  types  of  training  that  end  users  need. 
Or.  David  J.  Stang,  Ph.D.,  partitions  users  into  four 
categories  [Ref.  89:  p.  58]: 

1.  Non-Users  (Never  Have)  -  Those  who  never  have  used  a 
micro  (terminal),  but  will  soon. 

0.  Non-Users  (Never  Will)  -  Those  who  will  not  be  using 
micros  (terminals). 

;.  Surface  Users  -  Those  who  only  want  to  use  macros 
(terminals),  not  understand  them. 

4.  Oxp-  rienced  Users  -  Those  who  understand  and  use 
micros  (terminals). 


professional  management  or  consultation.  The  whole  market¬ 
ing  concept  is  neatly  tied  together  in  an  article  written  by 
Marylin  J.  Richardson,,  in  which  she  writes: 

Like  any  marketing  strategy,  one  for  an  information  center 
involves  identifying  the  target  market  and  then  defining 
the  appropriate  product  for  that  market;  establishing 
where  that  product  should  be  placed  so  the  target  market 
can  (and  will  v/ant  to)  access  it;  determining  the  price 
(people,  time,  and  money)  the  target  market  can  afford; 
and  implementing  a  blend  of  promotional  activities  to 
communicate  to  the  target  market  what  the  product  is,  how 
much  it  costs  and  where  to  get  it.  [Ref.  83:  p.  17] 


D.  TRAINING 

Training  starts  with  the  IC  staff.  Staff  personnel  must 
be  trained  before  they  are  able  to  teach  the  users.  Train¬ 
ing  staff  personnel  can  be  accomplished  in  any  manner  suita¬ 
ble  to  the  circumstance  or  organization.  One  unusual  method 
conducted  by  Michael  Steinberg,  the  information  specialist 
at  Corning  Glassworks,  is  explained  as  follows: 

"We  have  found  the  most  effective  way  to  train  our  consul¬ 
tants  in  the  use  of  a  product  is  to  find  a  user  who  knows 
]ust  about  as  little  about  the  product  as  our  new  consul¬ 
tant  does,"  one  member  (of  the  IC  staff)  says.  "We  sit 
them  down  with  a  couple  of  reference  and  training  manuals 
and  have  them  learn  together  to  develop  an  application. 

We  find  this  spending  a  whole  day  with  a  user  is  very 
effective  in  developing  that  extra  sense,  that  intuition 
kind  of  thing  about  the  package."  [Ref.  84:  p.  30] 

Training  the  user  is  of  equal  or  greater  concern.  It  is 
too  easy  for  users  to  choose  an  inappropriate  software 
packaue  for  their  application  or  even  worse  to  misuse  a 
software  package.  One  executive  using  a  spreadsheet  package 
caused  a  $55  million  sales  figure  to  be  in  error  by 
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damaging  if  not  controlled.  Miscommunications  are  also 

common.  The  following  example  represents  a  mi scommunication 

situation  that  could  have  been  successfully  handled  much 

earlier  had  some  form  of  marketing  been  considered: 

"Be  sensitive  to  the  possibility  of  conflicts,"  warns  Jim 
DeLong a  supervisor  in  the  information  center  of  the 
Michigan  Wisconsin  Pipe  Line  Co.,  Detroit.  "We  weren't, 
and  we  alienated  our  own  people.  They'd  say  things  like, 
'What  are  you  doing  talking  to  our  users?'  Some  called  us 
the  'misinformation  center'  for  awhi le . " . . . The  information 
center  staff  recently  held  a  meeting  to  explain  their 
program  to  colleagues  in  other  MIS  sectors,  and  hash  out 
differences.  DeLong  wishes  they'd  met  a  year  earlier, 
before  the  center  went  into  operation.  [Ref.  80;  p.  72] 

I’he  following  quotation  shows  another  situation  that 

needed  some  form  of  marketing  support: 

"I  (an  information  center  manager)  don't  understand  what's 
happening  to  our  Information  Center.  The  pilot  was  a 
great  success,  but  when  we  opened  our  doors  to  end  users 
it  flopped.  We're  all  set  up  to  offer  our  services,  but 
no  one's  buying."  [Ref.  81:  p.  53) 

Another  insight  in  favor  of  marketing  is  provided  by 

Gary  Livingston,  president  of  Information  and  Strategic 

Planning  Professionals  in  Lakewood,  Ohio: 

Managers  shouldn't  become  too  optimistic  after  achieving 
good  initial  results  with  the  IC,  warned  Livingston;  the 
strong  beginning  is  usually  due  to  the  enthusiasm  typical 
of  pioneering  users.  After  that  it's  slow  going:  "Thirty 
percent  of  the  corporation,  and  10  percent  of  top  manage¬ 
ment,  are  laggards  and  resisters,"  he  said.  [Ref.  82: 
p.  14] 

Marketing  the  IC,  however,  can  be  more  extensive  than 
the  initial  adv'ertising  of  the  IC's  capabilities.  It  can 
extend  to  post  -  i  mplementat  ion  support  as  well.  It  can  i  r: - 
\’ol\'e  detailed  strategy  and  planning  and  can  require 
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Once  you've  started  up  (the  IC).  you've  got  to  fight  damn 
hard  to  keep  your  credibility.  If  you're  any  good  at  all, 
you'll  be  overwhelmed  with  customers - -they ' 1 1  do  your  ad¬ 
vertising  for  you.  [Ref.  77:  p.  9] 

If  anything,  our  biggest  problem  was  holding  users  back  in 
order  to  keep  from  swamping  our  initial  [information  cen¬ 
ter]  resources.  We  have  1800  potential  end  users,  half  of 
whom  currently  have  access  to  the  computer.  [Ref.  78: 
p.  34  ] 


Nevertheless,  for  many  organizations.,  there  are  reasons 
to  consider  some  form  of  marketing  for  the  IC.  One  reason 
is  to  dispel  unrealistic  user  expectations.  In  an  article 
written  by  Robert  C.  Tesch ,  Sr.  and  Debbie  B.  Tesch,  the 
issue  of  user  expectations  for  management  information  sys¬ 
tems  is  discussed.  These  researchers  provide  some  insight 
into  the  importance  of  user  expectations  with  the  following: 

In  (Michael  J.)  Ginzberg's  study  ("Early  Diagnosis  of  MIS 
Implementation  Failure:  Promising  Results  and  Unanswered 
Questions."  Management  Science ,  April  1981),  results  sug¬ 
gest  that  users  who  hold  realistic  expectations  prior  to 
implementation  are  more  satisfied  with  the  system  and  use 
it  more  than  users  whose  pre-implementation  expectations 
are  unrealistic.  Ginzberg  identifies  five  areas  of  expec¬ 
tations  important  in  determining  user's  response  to  MIS: 

■>  .  Reason  for  developing  the  system 

2.  Importance  of  the  problem  being  addressed 

.1.  The  way  the  system  will  be  used 

4.  Systems  impact  on  the  organization 

5.  Criteria  used  to  evaluate  the  system.  [Ref.  79:  p.  64] 
Marketing  can  also  be  of  assistance  in  reducing  internal 

conflict  resulting  from  mi scommunication  and  misconceptions. 
One  common  misconception  is  that  technology  always  replaces 
peorl.e.  This  fear  of  people  losing  their  jobs  can  be  very 
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employ  countless  third-party  software  developers. 

[Ref.  75:  p.  16] 

The  IC  manager  who  tries  to  support  the  hardware  and 
software  already  in  place,  in  the  organization,  may  be  fac¬ 
ing  a  problem  that  has  no  economical  solution.  In  addition 
to  support  problems,  technical  problems  such  as  compatibili¬ 
ty  may  be  just  as  difficult  to  solve.  Even  more  dishearten¬ 
ing  is  the  fact  that  many  of  the  remaining  responsibilities 
of  the  IC  can  also  be  tough  to  manage.  These  problems  can 
only  get  worse  if  ignored.  Therefore,  developing  the  IC  as 
soon  as  possible,  harnessing  the  potential  of  end  user 
computing,  and  controlling  incompatibility  often  make  good 
business  sense. 

C.  MARKETING 

The  concept  behind  marketing  is  that  the  end  users  need 
to  understand  the  IC:  what  it  is,  what  it  can  do  for  them, 
and  how  it  operates.  The  users  need  to  be  convinced  that 
the  IC  is  a  better  solution  for  end  user  computing  and  that 
it  is  not  a  repository  for  more  backlogs  and  miore  user 
frustration.  On  the  other  hand,  the  IC  staff  needs  "to 
promote  existing  capabilities  without  promoting  new  business 
that  would  require  additional  staff  and  facilities  to  sup¬ 
port."  [Ref.  76:  p.  23]  There  is,  however,  an  argument 
igainst  the  need  for  mar''U''t  i  iii  .  The  following  two  quota¬ 
tions  suriport  tills  argument: 
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while  researching  new  techniques  and  tools  to  meet  their 
needs.  [Ref.  73:  p.  27] 

Success,  however,-  is  sometimes  attained  by  learning  from 
failure  or  mistakes.  For  completeness,  information  should 
be  sought  on  both  successes  and  failures.  The  following 
illustration  lists  one  manager's  mistakes,  and  offers  sever¬ 
al  good  points  for  IC  implementation: 

IC  manager  Joe  Bochino  (of  European  American  Bank)  reports 
that  if  he  had  to  do  it  all  over,  he  would  do  a  few  things 
differently.  He  would  take  more  time  to  educate  the  IC 
staf f - -teaching  two  or  three  people  the  entire  operation 
instead  of  the  whole  staff  piece-by-piece.  He  would  make 
a  separate  processor  available  to  the  IC  as  soon  as  the 
pilot  project  was  completed,  instead  of  having  to  wait 
nine  months  as  he  did.  He  would  have  the  data  delivery 
methodology  in  place.  He  would  better  coordinate  the 
personal  computer,  time  sharing  and  mainframe  disciplines 
under  a  single  manager.  He  would  guarantee  availability 
of  technical  expertise  by  having  a  systems  programmer 
report  directly  to  the  IC.  And  he  would  ensure  that  the 
IC  did  not  start  on  a  shoestring,  and  that  it  offered 
users  secretarial  and  administrative  as  well  as  informa¬ 
tion  support.  [Ref.  74:  p.  46] 

Tough  decisions  need  to  be  made  in  the  development  of  a 
successful  IC.  Some  of  these  decisions  will  be  discussed  in 
the  remainder  of  this  chapter.  The  toughness  of  these 
decisions  becomes  apparent  when  one  begins  to  appreciate  the 
enormity  of  the  task  at  hand.  This  enormity  is  expressed  in 
the  following  statement  made  over  a  year  ago  about  the 
number  of  available  microcomputers  and  their  associated 
so  f  t wa  re  : 

There  are  675  micro  hardware  products  on  the  market  today 
(December  1983)  and  154  manufacturers,  according  to  IRD 
(International  Resource  Development,  Incorporated).  The 
microcomputer  has  hit  the  industry  with  a  force  strong 
enough  to  support  some  100  microcomputer  publications  and 


69 


special  knowledge  not  ordinarily  encountered  by  managers. 
Therefore,  the  remainder  of  this  chapter  will  concern  only 
implementation  factors . 


B.  INTRODUCTION 

Organizations  tend  to  solve  ^-roblems  in  unique  ways. 

Implementing  an  IC  is  one  of  those  problems  that  is  sub]ect 

to  the  peculiarities  of  these  individual  organizations.  In 

some  cases  what  one  organization  may  call  a  success,  another 

organization  may  call  a  failure.  If  this  diversity  is  kept 

in  mind,  then  what  follows  will  make  more  sense. 

In  an  attempt  to  capture  the  overall  essence  of  this 

phase,  the  first  concept  to  be  covered  as  part  of  this 

introduction  is  the  idea  of  success.  One  author  writes: 

The  success  of  an  information  center  depends  on  a  service 
and  entrepreneurial  orientation,  the  right  tools,  the 
right  people,  a  supportive  climate,  justification  by  the 
end  user  and  data  availability  and  integrity.  With  such 
factors  going  for  it,  the  chance  of  success  greatly  in¬ 
creases.  [Ref.  71:  p.  141] 

This  entrepreneurial  orientation  is  sufficiently  explained 

by  the  following  two  quotations: 

He  (Ray  Youstra  of  IBM)  said  the  information  center  should 
be  run  as  a  business  within  a  business,  complete  with 
marketing,  measurements  and  a  board  of  directors.  "You 
must  report  back  to  someone  high  up  in  the  organization, 
not  just  the  DP  manager."  [Ref.  72:  p.  22] 

As  the  information  center  begins  to  expand  and  promote  its 
services,  tiie  DP  manager  must  remain  involved,  setting 
directions  and  d'afining  and  monitoring  objectives  while 
1 1  so  permitting  ihe  center  to  experiment,  ad]ust  throuah 
user  feedback  .and  innovate.  The  staff  should  be  encour¬ 
aged  to  work  iirectly  with  user  pe  lonnel,  treating  them 
as  custonu'rs  anci  responding  immedia-el\'  to  their  problems 


6  8 


>.si  •_  I,.--  application  ana  l  tii.-y  nt'Oa  t  :>  sn;:>port  the  oata 

p !' o;;oa'a  i  :  1  :  in  :c  r  tracnt  ami  re-f'nr  ’arae  a  rcj  1  ;  ca  1 1  ons  :o  ttie 

aat.i  ;  >■ '.cv-np  in  ;  .ic- laa  r  ^  me  n  t  .  nxxori  Corpora*  loi;  a  ccompi  i  she - 

:•  .  :  n  TO  *  toilciwinc  rcanrn'-r: 

.■■iien  clii'Cty  come  to  tOi-  CSC'  (IC)  tor  aS'.'ice  on  a  new 
;c:>p  1  1  Ca  t  :  on  ,  a  team  member  aiscasses  the  p'robl  em  witli  trjem 
a:.  1  '  \e;  ,  t  n- p  .'io'w  bfc-st  t r,  nancllf'  their  neeCis  .  For 
t  r  a  1  i  ti  t  r  m'wa  rc.  applications,  the  CSC  (IC)  member  simply 
reccjmm.enas  an  at'proacli  or  a  tool.  For  more  comoiex  prob¬ 
lems,  a  seconn  CSC  (1C)  me-niper  is  usually  called  in.  to 
he  it'.  If  the  application  is  complex  enough  to  require 
contracting  for  conventional  development  by  system.s  pro¬ 
fessionals,  the  client  is  directed  to  the  appropriate 
peorde  in  otner  parts  of  the  organization.  [Kef.  "'10: 

1  d  v.  ' 

;  '  •  '  '  ■  J 

.•■■.ne>tner  important  cons  id€;ra  t  icn  is  determination  of  the 
level  of  support  to  be  offered.  Although  this  is  also 
situation  dependent,  it  is  generally  thought  that  consult- 
ar:ts  shouiii  -  ot  program,  for  the  end  users.  Jeffrie  Shelley, 
i'.ina'ier  ot  the  IC  at  the  Chicago  Transit  .Authority,  cla.ims 
"Tne  information  center  staff  shoi.ldn't  do  any  coding, 

.  *  1  '  ieve  1  op  its  own  'oack  J  oq  .  "  [Ref.  ill:  p  .  141 

■;nina  n.c'p  that  do  not  obiect  to  consultants  doing 
■  ("or  end  users,  often  place  restrictions  on  coding  so 

u  1  t  a  n  *  s  are  only  minimally  involved.  The  maiority 
h'  I'-rs  seem  to  f, allow  the  advice  in  the  next  two 
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r::.;-  L'-^iitors  shouici  lirn.it  tlii;ir  support  uct  1 1’ 1 1  i  es 

;  ;i:i;  •  ;  .;s.:rs  wit!i  jn-housc-  consulting  serv- 
.  .  .  .  ( .1  r  r  •  •  n  )  Brown  (MTS  director  at  Hercules  Incor- 
iv'.;  lospac*:.'  Jivision)  urued  inf  ormat  i  on  center  staff 
1;  n'.'io  i  iritensive  i  n'.’ol  I’en'c  nt  in  their  clients' 
warr-  n:- 1  op-;- nt  pr ]  oct  s  .  .  .  .  "V.  e  aon  '  t  create  any 

‘ ;  1 ;  d  es  ,  ”  irrowri  said.  "Wo  '  r<r-  striving  for  user  self- 
iio-ri'oy.  coal  is  to  hrMp  users  to  help  them- 

■  -  s  .  "  ;  S-  • :  .  vi .  l  n  j 

'u-  , ; ,t  i  1  a  o :  1  1  t  y  oM  consultants  and  the  consrsten- 
t.rn-i:  jij'.ocr-  ■.\;ri.'S  t  ro'"  organization  to  organization, 
i ."'t' 1 1,- s  ot  ]:(}.:  cori-ora  1. 1 '■)r;s  treat  these  rerpu  irements 

e  -  -  I:  r;rn',-  :  '  ■  u  ; 

usC'  of  .‘s  size  and  purpose,  the  CSC  (  IC  at  Exxon 
orojtiori'  do-'-s  not  -write  applications  for  its  clients; 

wo-,.ld  not  facilitate  "end  user"  computing.  And  -while 
(IC)  sori’ices  are  available  on  call,  there  is  a  four 
limit  on  consultation  or  technical  assistance  per 
icution.  T’his  ensures  that  no  single  user  monopolizes 
ccuiter.  [Ref.  114:  p.  13b] 

service  consultants  operate  the  walk-in  facility  from 
to  4:30  pm  ei’cry  ■worhinq  day,  although  employees  can 
nge  to  -use  the  center  24  hours  a  day,  seven  days  a 
■fli'..'  consultants  conduct  required  introductory 
S'_'S  for  center  users  and  spec  i  cU  1 1  zed  courses  in  the 
uus  sc.ft'ware  tools.  Tnoy  also  assist  in  designing 
.til  a  pod  1  ca  t  1  ons  and  applying  the  tools.  (Kef.  115: 
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ch  has  Deen  written  about  IC  hardware,  especially 
omputers .  Therefore,  treatment  of  this  topic  will  be 
At  this  le’iel  in  tne  SDLC,  policy  and  detail  are 
ant.  Hardware  can  De  helpful  or  it  can  hurt  the  IC, 
inu  on  the  way  it  is  controlled.  If  control  is  too 
r  ‘ -w  neopie  will  use  the  IC.  If  control  is  too  loose, 
will  turri  ;ntc  a  gicantic  expense  with  little  return 
f'Sto.ent.  There  is  no  picrfect  amount  of  control. 

IS  s 1 tuat lona 1 1 y  dependent,  A  comparison  between 
;  :.n  p’OW'_’;  and  costs  is  made  in  tne  follo'winn  article 

irur-,  ir-aeily  loaded  or'.n- r  e  r  runninc  TSO  ,  the 

:;ardware  cost  r  n  ■  pi'ii’ide  ads-quate  I'esponse  fo 
1!  :  :  :  ‘  lon.i]  users  r.iuht  be  leOCpioiO.  Tc  u.i’e  the  saiTi- 


j  s  n  a  t 


i  co:npl.'tc  cos  t_  /  bene  f  j  t  analysjs  it 
I'll  ,1  sa";|.'].,'  oi  so.-ne  ot  the  type  or  trade -offs  that 
a  ravel  re  in  the  IC.  The  t.  i^;h  cost  of  IC'  hardware 
.iaS’,_'S  fieipj-iTit  scrutiny  and  r  t-iiu res  effective  utiii- 
Tne-  toilowina  -yaot  a  1 1  on  aadresses  t  ne  effective 
'icu.  of  per  soil  il  computers: 

a  i  iiersonai  coitiput-'-r  to  someone  who  is  not 
•-■stO'd  in  Oh-:.,  I ‘;c;ar  a  less  of  v/hetiier  or  not  the  person 
into  t'ne  taracte'i  aroup,  is  flushino  nioney  dov/n  the 
....trjday's  PCs  r-'-'inire  an  interest  nigh  enough  to 
a  St  t  :u-  ''ery  f  rust  rat  inq  and  clumsy  learning 
s....t>ri  the  otner  .hand,  denying  one  (PC)  tc  someone 
ssiv'*.-'y  interested,  ana  in  regardless  of  targeted 

IS  lust  as  ecu  a  waste.  If  necessary,  such  people 
be  meved  or ca n i ca t i ona 1 1 y  before  they  are  flatly 
access.  Tho  aggressively  interested  employee  will 
proauctive  uses  for  the  PC  that  no  one  else  dreamed 
Ko  f  .  1 d  0 :  pp .  J  D  -  36  ] 

lanizations  are  loariing  microcomputers  to  employees 
r  p-'-uiK  demand  periods,  as  a  backup  for  broken  micro- 
rs,  and  as  a  m.eans  to  test  out  a  new  piece  of  equip- 
■ ;  s  .  I  I  :  n .  i  ,  12  2:  p .  62,  123:  p .  161.  Some  even 
'  :  employees  ta’-',e  microcomputers  home  [Refs.  124: 


most  talked  about  topics  is  personal  computer 
Compatible  computers  allow  sharing  of  pro- 
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tiiat  app<_-ar  to  be  compatible.  Suppose  everyone  in  the 
er  uci  n  1  na  1 1  ori  had  been  carefully  restricted  to  the  IBM  PC, 
dB.eSh,  and  WORDPLUS.  We're  in  great  shape,  right? 
But  half  of  them  are  running  under  DOS  Version  1 ,  some 
under  Version  1.25,  and  the  rest  under  Version  2. 

■'•.s  S'oe  X  a  t  ed  \'t_;rsions  of  the  application  products  ran  or;  the 
t  riunarnr  1  a  te  machines.  Some  of  the  software  has  buus  that 
‘  fixed  1  r.  later  versions.  Some  use  coloi  ,  some  don't, 
doti-n  cl  1 1  erw  careful  disk  organization  under  subdirectories, 
sonie  uor. ' t  .  But  everyone  is  usina  the  same  products.  Is 
;  rosi'  still  a  rose...?  And  this  is  tne  easy  case  where 
c-.’eryone  is  usinq  one  machine  and  one  set  of  products. 

Lv,;t,  tile  disl.s  and  files  are  not  interchangeable,  even 
here.  [Ref.  t 2 6 :  p.  19! 

Ir.  1  ted  Tecnnoiogies  Corporation,  John  Bennett,  the  DP 
r  -.'Ctor  ,  describes  a  minimum  compatibility  policy  as 


Cl  ••■on  this  loose  structure,  there  are  no  corporatewide 
preferred  vendor  lists,  said  Bennett,  as  each  division  has 
Settled  on  the  type  of  equipment  that  it  feels  is  most 
neneficial.  The  only  corporate  policy  is  that  the  PC  have 
;!  rTunimum  of  256K  bytes  of  RAM,  a  graphics  card,  printer 
inu  niqn  resol  ition  monitor.  [Ref.  127:  p.  51  ]  ’ 

;i  managers  should  be  concerned  with  other  haraware 

"a. is  us  Well.  The  IC  should  educate  their  end  users  on 

;  ;-.-ip>'r  -are  of  diskettes  (e.g.,  no  bending,  no  touching 

ici  L  c  surface,  use  only  felt  tip  pens  to  write  on  the 

.  s  ,  us'c  bacKup  procedures  often,  store  backup  copies 

:-site,  and  avoidance  of  magnetic  obiects)  and  other 


1 :  e  n  1  .  !  .1  e 


IC  should  ensure-  adequate  quality  power  is 


1  1  a  I'  1  o  ,  p 


rovide  and  teach  security  of  equipment  and  data. 


i  v  d:r.-  other  necessar\'  Guidance. 
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BCittwaro,  Ls  rnoritioned  bocauso  of  the  unique  approach  it 
i  i  s:  ■  1  a  y  s  ; 


'i'!ie  rsc  (  IC)  :io>'S  not  have  the  authority  to  dictate  which 
to.'ds  tv'  US''-.  Ic.  prcii'idt'  thorouqti  support,  however,  the 
I'SC  (Ii')  "'.in’:  ii;i;it  its  tool  ret  to  a  manaqeablo  size. 

:  :i- •  i'-:- f  or  >;■ ,  t  hf  CSe  (IC)  has  a  simple  policy:  if  clients 

th*-  tiools  r  •acontniended  by  the  CSC  (IC),  the  door  is 
always  cisi-.-n,  ariL;  the  CSC  (IC)  will  provide  complete  and 
r'an-v-.s.  i  V’.-  si-ri'ice.  If  clients  use  brarid  X  of  their 
’  I'.v:.  inoasin:,  t  m  CSC  (IC)  will  proi’ide  only  minimum 
sar-.-.C"  aiij  on^y  after  meeting  the  needs  of  its 

:  .lai’  ci  lasts..  'i'nis  poli-i-y,  applicable  to  both  nard- 
•••'at.'  inu  h.ds  been  quite  successful.  [Ref.  126: 

on  .  ;  ’  4:;  : 


C.  Soi'TWAKi: 

Choosinq  the  right  software  can  mean  the  difference 
O’tween  success  and  failure  for  an  IC.  Allowing  end  users 
t choose  may  result  in  the  use  of  bundled  software  that 
Cam;'!  with  the  user's  personal  computer  reciardless  of  how 
v,c)d  or  now  appropriate  the  software  niay  be  iRef.  129:  p. 

-i  ■  ;  .  over,  'worse,  the  end  users  may  be  using  each  other's 
scrt'ware  illeqaliy.  John  Seymour  writes  the  following  on 
'h.  IS  topic: 

rc’cent  miauazine  article  indicated  that  there  are  150,000 
tv:  i store  1  copies  of  a  leading  latabase  package  in  use  and 
at  least  that  many  in  use  that  c:re  not  registered.  I'd 
eat  the  estimate  ot  unregistered  copies  is  very 
.:'.''ns'~’r  \'a  1  ve  .  i_n.  a  corporate  scale  this  is  qrand  larceny. 

...  *1  *  .  _  t  .  K  ■  ,  “i  ^  , 

s-cftwar-j  lev'e  1  opi- r s  arc  startinc  to  pursue  flacrant 

■  ;o  ’.v.''-  iiusf'rs  ai'.d  takina  them  to  court.  Most  corpora- 

■  .  so.  uftc'r/:  t  n-a  1 1 1  n'.;  fines  but  car.  ill  afford  the 

■  :  :  ;  :  ‘  ba  :  ;oi  s  s :  n  : o;  pu i v  i  c  sector.  dne  firm, 


i 


ti 


4 

) 

g 


i 


I 


» 

1 


Pacific  Gas  and  Electric  Company  of  San  Francisco,  solves 
the  software  piracy  (illegal  copying)  probleni  with  what  has 
been  termed  a  software  site  license  as  described  in  the 
f  o  1  ]  ow  1  n  c; : 

he  don't  bay  a  copy  of  the  package,  we  buy  the  right  to 
use  it.  In  exchange,  we  niake  sure  our  users  will  not  call 
the  vender;  we  take  over  the  support  f unct i on . . . . so  far 
tne-  vendors  have  been  amenable  to  a  sirigle,  up-front 
payment,  along  with  specified  payments  for  upgrades.  "We 
do  not  pay  per  copy  royalties,"  Buckholtz  said....PG&E 
also  pays  for  the  right  to  reproduce  manuals  for  the 
software.  [Ref.  131:  pp.  95,  100] 

Corpc.rat  1  ons  that  are  interested  in  controlling  software 

piracy  can  follow  the  five  steps  suggested  by  G.  Gervaise 

bavis  III  and  paraphrased  as  follows  [Ref.  132:  p.  82): 

■  .  Create  a  written  policy. 

2.  Communicate  that  policy. 

hooK  around  the  company  for  violations. 

4.  Take  action  if  piracy  occurs. 

5.  Work  with  software  developers  (e.g.  site  licenses). 

It  IS  helpful  to  put  software  costs  in  perspective  by 

comparing  mainframe  software  to  microcomputer  software.  A 

simplf  comparison  is  provided  below: 

An  obvious  difference  between  mainframe  and  micro  software 
IS  cost.  Many  mainframe  packages  sell  for  about  $60,000 
to  Slc0,OiJ0.  Most  m.icro  packages,  by  contrast,  cost 
between  $30  and  $1,000.  The  individual  price  tag, 
hc)we\'er,  may  be  deceiving.  MIS  executives  usually 
purchase  only  a  few  copies  of  a  mainframe  packaae,  but 
ricro  software  is  often  purchased  in  volume.  If  there  are 
Vi'i  pcs  in  vour  oraanixation  and  yov;  deci  !_■  that  each  one 
sh'U’,.l,i  tiav'-  a  coov  of  a  selected  Situi  na  exa  ae  -  -  b  i  ngo  1 


.■  list  softw^ire  detail  to  be  discussed  is  inteqrated 
r  .  "ir.toqrated  software  refers  to  software*  that 
two  rt.iriimal  conditions:  it  offers  two  or  more  major 
c^itiC-ins  and  allows  information  to  be  transferred  be- 
t.t^aSf  applications  with  a  minimum  of  e  f  f  or  t ~  per  naps 
1  '''  K.eystroKes  and  in  one  or  tv/o  minutes."  [Ref.  134: 

T.'ie  benefits  of  inteqrated  software  are  paraphrased 
tollowinq  list  1  Re-f  .  135:  p.  601: 

Requires  le-ss  learning. 

Eliminates  the  need  for  entering  data  more  than  once. 

Offers  three  to  six  major  applications  at  a  coi;t  per 
application  far  lower  than  the  unit  cost  of 
independently  purchased  software. 

Moi’ing  from  one  task  to  another  may  require  only  a 
Keystroke  of  two. 

eryone  wants  integrated  software.  This  is  a  difficult 
a::  1C  manager  to  accept.  One  vendor  states:  "What 
SfeiMC!  IS  a  rebellion  against  integrated  packages 
C'r.tc-  peor-le  who  don't  need  them."  [Ref.  136:  p.  20J 
on;e  .neopie  are  finding  is  that  integrated  software  is 
om:  d  1  cat -.-d  and  therefore  is  more  difficult  to  use. 
simu-Ier  packaqe  can  meet  the  needs  of  end  users,  they 
want  i  >  bf  stuck  with  the  more  difficult  package. 

N 0  I  ! >' 0  AMii  CO?\ TR OL L I  NG 

:  r-er.s  can  fit  under  the  managing  and  control  lina 
:  .  Ur-  cont i  o'uers  la  1  tone  in  this  area  is  data 


<”*0  s  s  . 


The  logic  of  those  ip  favor  of  direct  access  is 


i-iy  explained  in.  the  next  quotation; 

"  i’hf  only  -way  that  information  centers,  and  personal 
c^jinpnters  tied  to  information  centers,  can  reacn  their 
true  potential  is  by  way  of  easy  access  to  the  corporate 
ujlaoase,"  we  were  told.  "And  this  means  the  database 
itself,  not  an  extract  version  of  it."  An  extract  version 
may  not  be  up-to-date,  or  may  not  have  tlie  data  that  a 
pa-'tiruiar  user  urgently  neeas  ,  they  said.  [Pef.  13"':  p.  u 

ere-  is,  however,  a  more  popular  approach,  which  extols  the 

rtues  of  extract  files  or  databases.  The  following  are 

dirples  of  some  of  these  virtues: 

Wnen  an  extract  of  the  prode.ction  file-  is  taben,  data 
values  can  Pe  put  in  a  standa’'d  format,  obsolete  fields 


can  be  stripped 

of  f  , 

control  tot 

a  is  ■•an  ’■‘' 

CheCKed  to 

ensure  accuracy 

and 

•-■arious  comp 

u  t  a  L  ;  o  n  f-  c 

an  be  performed 

a  s  r  e  q  u  e  s  t  e  -d  b  y 

the 

user  .  [ Kef  . 

1  1  R  ;  r> .  :  1 

- 

o  wavs  that  extr 

act 

files  and  da 

tabas-,-s  ar 

e  handled  are 

l.cated  in  trie  followinn  two  statements; 

(John)  Nylen  (IC  supervisor  at  Siqnode  Ind'ustries) 
rrotects  corporate  data  by  not  allowing  ar.y  of  the  end 
iser  s  access  to  the  production  files  duririu  the  first 
snift  processing.  Anyone  who  does  development  work 
ucCfSS'.'S  extracted  versions  of  those  files.  If  they  wish 
to  run  auainst  tne  full  production  file,  they  submit  the 
o;r  an'!  it  runs  in  batch  at  night.  "We  more  or  less  na\’e 
n-i'Xt  ujy  reportina,"  he  explains.  "That's  served  our 
purpoS'--s  well,  however,  because  people  previously  were 
used  to  thr-oe  to  six  months."  (Ref.  139:  p.  27] 

bs-urs  (at  the  trazilian  subsidiary  of  the  Chase  Manhattan 
•nmr',  banco  bar)  cannot  access  production  data  without 
first  filino  a  request  with  the  information  support  center 
(1C).  Tfie  support  center  (IC)  staff  defines  the  fields 
tnat  ar-'-  neea-od  from  the  central  da'ra  base  and  copies  them 
on  a  ■  s  ri  tl.at  IS  accessible  froc  the  user's  virti.al 
:-,a  on  1  n-iS  .  'Ref.  l  4  a  ;  p  .  29  ! 

A:.;tn--r  ur'-a  of  manacinu  ana  controllinu  is  the  concern 
1  .-a.i;'  t:.-  Mp-i  users  are  aoiriu  with  tnis  technolony. 


iiiiusiidi  aspects  dealiivg  with  coinputers  as  status 

cij'.jls,  ttif  problem  of  "technostress",  and  technology  in- 

"uat  ion  ar.'-‘  >■•:<  p  1  a  i  nod  -well  in  the  followinrj  quotations: 

.  .  .  coriipu  to  r  s  a  n._l  word  processors  have  become  status 
symn^iis  tC'  o''eryone  from  secretarie'^  to  OTigineers  and  from 
ariaiysts  to  e/.ecutjves.  The  status  has  been  refined 
beyona  the  Cadillac  and  the  Mercedes.  There  is  anxiety  on 
t  t'O  part  of  those-  wno  don’t  have  them  yet,  made  worse  by 
one  ov.'nors  who  eniphasiuo  how  easy  they  are  to  master.  The 
easier  everyone  says  they  are,  the  easier  it  will  bo  to 
loot,  stufjict.  [Ret.  141;  p.  34] 

lecunost  ress  .  .  .  1  iefined  as  the  inability  1.0  adapt  to 
computers.  (Craig)  Brod  (author  of  a  booh  on 
t  ecr.n.ast  r-i‘ss  )  identified  two  forms  of  the  phenomenon.  The 
first  IS  the  feeling  of  beine  overwhelmed  by  the  machines 
Co;  IS  net  confined  to  the  working  level,  but  extends  all 
into  t  ne  executive  offices.  The  second  results  in 
;  c-  oe.roming  ma  ch  me  - 1 1  ke  ,  in  that  they  overidentify 
n-i-  computers  and  lose  the  interpersonal  SKills  that 
■  :.a;  .  t:.  to  aeal  effectively  with  people.  [Ref.  142: 


managers  must  monitor  whether  users  are 
n  center  tools  as  their  daily  work  rather 
augmentation.  "Users  oecome  so  engrossed 
and  how  much  fun  it  is,  that  they  are 
;;ee-whi7  things,"  confirms  one 
er  iranaoer  ,  "and  the  grunt  work  doesn't 
"  If  that  happens,  the  information 
t  with  the  user's  department  manager  to 
cations  can  be  simplified  or  eliminated. 


T"  stren.-iths  and  weak.n-esses  when 
t  or  a ccon;p  I  1  sh  ing  a  tasK.  Cno 
ainst  and  which  aranuallv  occurs  is 


1;  s . df  eftects.  It  turns  each  person 
'::p;ter  operator,  datii  entry  clerk, 
chief  financial  officer  said,  "I 
1 '■  n  ,  d ‘i-.;  -  a  -  year  financial  analyst, 


.1 : 1  1  r‘ s  so:i!':-  pr  rir.  i ,  also.  Trie  full  brunt  of 

n  1  r  U’U  p're  1  1  f  c-ra  t  ;  on  ol  o' i  crooornputer  £  does  not  ncces- 
ria'.''.  ’■  ro-st  on  .'a-  s:!r>..  1  dors  of  tlie  TC  niana-nc-r. 

■■'.a ,  in'  .■:i.ir;aur;i  for  Tr-iaroio  Corporation,  supports 
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arty  Ma  1 1  e-r'  said  it  is  the  laeal  system  for  his  company, 
K  f  t  .  ’  4  r  ;  p  .  n  u  i 


T’heroi  are  many  administrative'  tasks  that  impact  on  the 
either  in  s  t  a,  f  f  tine  or  ;  r.  other  resource  utilization, 
es,  such  as  pub' 1  i  sr.  i  na  a  n'^-ws  letter  ,  handling  supplies, 
ntaininu  'ibrari'es,  a.nd  organizing  users  groups,  quickly 
in:  to  C'-onsume  more  staff  resources  than  allocated.  The 
:C  ma  na  :ie;  s ,  .'-'arie  .Sv/anson  and  Ann  Staton,  at  First 
...■nai  bao.K.  of  M  i  nnoagiol  i  s  ,  agree  that  this  is  the  case  in 
;  t '  1  1 ow 1 n  1 ; 

re  !  surprise  v;as  the  amount  of  "admini  stri'iia"  involved 
util  r  r.  1  n  o  their  "business  within  a  business."  Says 
w.cison,  "Nobotiy  told  us  how  much  time  it  takes  to  do  the 
lass  scriadu  i  1  no  ,  promotion,  billing,  publicity  or  any  of 
:.e  day-i'o-'iay  activities  that  have  to  be  done,  but  that 
:;ti‘ifore  witn  the  actual  worVi  of  the  information  center." 

Mr:  tr .  4  A  ] 


writes  about  trie  admi 


It  rat  ion  of  software: 


-stration  of  purchased  software,  especially  in 
■'S  at  wt.ich  It  IS  Deina  purchased,  is  a  s-  inifi 
packaaes  need  t'O  fw'  reoistered  bi  .‘tial 


r-en;iOi  . 


Id 


and  now  version.  .ef^d  t 
■fcra  distribution  is 
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But  graphics  are  also  easy  to  misuse.  There  are  numerous 
instances  where  senior-level  end  users  spent  a  half  hour 
or  more  in  front  of  a  crt  to  get  one  graph  just  right  or 
tried  to  use  a  tv;o  pen  plotter  to  create  several  transpar¬ 
encies  at  one  sitting.  These  situations  are  a  waste  of 
time  and  manpower  because  an  administrative  group  now 
exists  to  create  such  charts.  The  CSC  (IC)  is  now 
searching  for  more  user-friendly  graphics  tools  while 
instructing  clients  on  using  the  current  ones  more  effec¬ 
tively.  [Ref.  157:  p.  142] 

A  bank  vice  president  creates  slides,  almost  instantane¬ 
ously,  for  30  cents  each.  The  old,  traditional  approach 
took  several  days  and  cost  $35  per  slide.  She  now  uses 
slides  for  routine  presentations  rather  than  only  on  spe¬ 
cial  occasions.  [Ref.  158:  p.  246] 

Beth  A.  Benson,  a  financial  graphics  programmer  at  Johnson 

and  Johnson,  has  captured  the  topic  of  graphics  use  in  the 

following  quotation: 

We  had  an  established  need  for  some  level  of  graphics 
because  management  was  overloaded  with  paper  and  computer¬ 
generated  reports;  it  needed  to  see  less  detail  and  more 
trends.  Some  of  our  users  were  creating  charts  manually 
on  a  routine  basis,  while  presentation  graphics  were  con¬ 
tracted  out  to  a  printer ....  Computer  graphics  applications 
are  increasing  constantly.  As  companies  grow  and  the 
amount  of  data  increases,  the  need  for  simplification  and 
exception  reporting  increases.  [Ref.  159:  pp.  47-48] 

The  last  opportunity  to  be  examined  is  a  particular 
system  installed  at  the  University  of  Texas  Law  School.  It 
is  described  as  follows: 

The  Kurzwell  scanning  and  processing  system  is  different 
from  other  OCR  (optical  character  recognition)  scanning 
systems  because  it  can  scan  and  recognize  almost  any  font 
in  typewritten  or  typeset  materials  in  sizes  ranging  from 
small  six-point  type  to  relatively  large  24-point  type.... 
In  this  way,  rekeying  is  eliminated,  saving  both  time  and 
typographical  errors.  [Ref.  160:  pp.  128-129] 


VII.  REVIEW  PHASE 


A.  PURPOSE  OF  THE  REVIEW  PHASE 

The  purpose  of  the  review  phase  is  to  evaluate  the 
effectiveness  of  the  SDLC  and  the  management  techniques 
applied,  and  to  determine  whether  projected  benefits  have 
been  utilized  and  whether  enhancements  are  desirable  and 
j  ust if iable . 

B.  DEVELOPMENT  RECAPITULATION 

The  objective  of  this  activity  is  twofold.  The  first 
requirement  is  to  determine  the  appropriateness  of  the  SDLC 
methodology  to  the  problem  of  end  user  computing.  The 
second  requirement  is  to  evaluate  the  degree  of  success  of 
the  pro]ect  development  team  in  the  utilization  of  the  SDLC 
methodology  and  the  documentation  of  mistakes  for  future 
reference . 

Determination  of  the  appropriateness  can  be  difficult. 
As  one  author  states: 

Analytical  and  modeling  techniques  that  were  inadequately 
understood  and  improperly  applied  by  planning  profes¬ 
sionals  will  soon  be  applied  even  more  improperly  by 
staffs  throughout  corporations.  Few  practitioners  under¬ 
stand  the  limitations  of  business  analysis  and  modeling. 
Now,  anyone  can  have  at  desktop  enormous  computer  power. 
This  distributed  computer  power  combined  with  the  naivete 
bodes  national  economic  mayhem.  [Ref.  161:  p.  9] 

The  prejudice  of  ignorance  is  difficult  to  overcome.  In 

addition  to  ignorance,  there  is  another  prejudice  which 
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should  be  avoided.  This  prejudice  is  loyalty  to  a  particu¬ 
lar  methodology.  It  is  like  the  child  who  tries  to  force 
the  square  peg  into  the  round  hole;  it  does  not  work  very 
well.  John  Seymour  adds  some  commentary  to  this  idea: 

And  we  all  have  our  religions  when  it  comes  to  methodolo¬ 
gies,  implementation  techniques,  brand  names,  and  stand¬ 
ards  for  judging  who's  good  and  who  isn't.  And  most 
methodologies  work  under  the  right  circumstances,  and  fail 
under  the  wrong  ones.  [Ref.  162:  pp.  15-16] 

The  second  requirement,  to  determine  how  well  the  SDLC 
study  methodology  was  utilized,  can  be  based  on  a  brain 
storming  session  at  the  end  of  the  study  and  an  examination 
of  the  documentation  that  was  accumulated  throughout  the 
project.  Complaints  from  team  members,  the  length  of  actual 
development  time,  and  the  amount  of  duplicated  effort  are 
all  indicators  of  the  team's  performance. 

C.  POST  IMPLEMENTATION  REVIEW 

The  purpose  of  this  review  is  to  evaluate  how  well  the 
system  has  performed  in  meeting  original  expectations  and 
projections  for  improvement,  and  to  identify  any  maintenance 
projects  that  should  be  undertaken  to  improve  or  enhance  the 
implemented  system.  In  other  words,  it  is  a  review  of  how 
well  the  IC  is  doing,  and  what  else  can  be  done. 

This  review  should  be  formal  in  nature  and  should  be 
conducted  at  appropriate  intervals  to  be  decided  at  the  end 
of  the  implementation  phase.  It  should  include  an  examina¬ 
tion  of  productivity  measurements,  a  review  of  any  audits 


conducted,  a  review  of  the  use  of  the  latest  technology,  and 
an  evaluation  of  a  survey  of  the  end  users.  The  business 
objectives  should  be  reconsidered  in  case  there  has  been  a 
change,  and  also  to  reinforce  the  basic  underlying  premise 
of  the  purpose  of  the  IC.  Lastly,  there  should  be  some 
provision  to  conduct  partial  reviews  whenever  the  situation 
changes  or  the  circumstances  warrant. 


VIII.  CONCLUSION 


A.  GENERAL  OBSERVATIONS 

The  IC  seems  to  fill  a  gap  in  the  traditional  management 
structure  of  most  organizations.  The  traditional  hierarchi¬ 
cal  organization  lacks  he  ability  to  control  and  maximize 
the  productive  use  of  end  user  computing.  It  would  be 
easier  if  these  organizations  were  organized  around  func¬ 
tional  capabilities  vice  the  normal  departmental  structures 
or  product  lines.  Most  organizations  find  that  the  func¬ 
tions  provided  by  the  IC  help  to  cross  rigid  departmental 
boundaries  but  have  potential  to  cause  problems  if  not 
properly  controlled.  As  one  author  writes: 

Information  is  such  a  critical  resource  that  some  com¬ 
panies  find  its  care  can  no  longer  fall  under  several 
different,  and  sometimes  uncoordinated,  domains.  These 
businesses  are  setting  up  information  centers  that  not 
only  help  users,  but  also  draw  all  aspects  of  information 
processing  under  one  umbrella.  [Ref.  163:  p.  75] 

Even  the  manner  in  which  an  IC  is  implemented  can  affect  the 
productivity  of  one  department  over  another  and  can  make  a 
major  impact  on  the  corporate  strategy.  Some  control,  how¬ 
ever,  is  better  than  none,  and  implementing  an  IC  is  almost 
always  more  productive  than  not  implementing  an  IC.  Vaughn 
Merlyn  supports  this  idea  when  he  writes: 

The  vast  majority  of  Information  Centers  are  implemented 
below  "par",  and  it  seems  that  there  are  two  "laws  of  the 
Information  Center"  that  are  inescapable.  The  first  law 
is,  "It  IS  virtually  impossible  to  implement  an 


Information  Center  so  badly  that  it  will  not  experience 
success  early  in  its  life."  The  second  law  states,  "It  is 
virtually  impossible  to  implement  an  Information  Center  so 
well  that  it  will  not  experience  significant  problems 
later  in  its  life."  [Ref.  164:  p.  29] 

End  user  computing  expertise  is  often  lacking.  General 
managers  find  not  only  the  technology  difficult  to  master, 
but  the  unique  management  requirements  are  equally  burden¬ 
some.  This  is  partially  because  the  IC  concept  is  new. 
Likewise,  the  amount  of  resources  required,  to  remain  cur¬ 
rent  in  the  fast  moving  field  of  computers,  is  prohibitively 
uneconomical  for  most  departments  and  requires  the  resources 
and  coordination  of  a  larger  body,  usually  the  corporation 
itself.  Mostly,  because  of  these  reasons,  ICs  are  gaining 
popularity  and,  in  some  cases,  are  approaching  the  status  of 
being  a  necessity: 

IBM  claims  that  42  percent  of  its  largest  computer  users 
have  these  centers  (ICs),  and  a  recent  survey  of  32  major 
companies  found  that  two-thirds  expect  to  support  two  or 
more  information  centers  by  1985.  [Ref.  165:  p.  30] 

It  is  estimated  that  some  40  percent  of  mainframe  instal¬ 
lations  in  North  America  have  Information  Centers--whether 
or  not  under  the  name--in  place.  The  majority  of  the 
balance  are  planning  to  establish  such  centers.  The  cor¬ 
porate  use  of  personal  computers  is  also  spreading. 

[Ref.  166:  p.  12] 

Management  is  also  finding  that  end  users  can  not  be 
stopped  in  their  fervor  for  end  user  computing.  End  users, 
left  to  their  own  devices,  often  misuse  the  technology 
because  of  lack  of  skills  or  knowledge,  poor  application  of 
resources,  or  infatuation  with  the  technology.  This  results 
in  suboptirnal  productivity  and  poor  return  on  investment. 


Control,  often  in  a  form  similar  to  the  IC,  is  usually 
required . 

In  a  survey  conducted  in  1982  and  updated  in  1984,  96 
northeast  Ohio  organizations  answered  questions  about  per¬ 
sonal  computing.  These  businesses  showed  gross  revenues 
ranging  from  $50  million  to  over  $2  million.  Figure  8  shows 
the  results  of  this  survey.  Because  this  survey  was  not 
scientifically  generated  or  analyzed  it  can  not  be  con¬ 
sidered  a  true  trend  analysis  nor  can  it  be  considered 
statistically  significant.  It  is,  however,  better  than 
intuition  alone.  The  benefit  of  this  survey  is  that  it 
compares  personal  computing  information  from  the  same  organ¬ 
izations  over  a  two  year  period.  This  provides  general 
trend  information.  Unfortunately,  the  limited  geography  of 
the  sample  and  absence  of  scientific  process  limit  the 
effectiveness  of  its  results.  [Ref.  167:  p.  128] 

APPARENT  TRENDS  IN  PERSONAL  COMPUTING 

BASED  ON  96  ORGANIZATIONS  SURVEYED  (1982-1984) 

1982  1984 


Companies  with  business  personal  computing .  13  68 

In  the  selection  and  acquisition  of  personal 
computers,  the  MIS  department  has: 

control  over  the  selection  process .  2  52 

advisory  capacity  only .  6  13 

no  input .  3  3 

Formal  user  training  program .  0  26 

Formal  help  desk .  0  33 

Company  planning  for  personal  computing .  0  8 

Local  area  networking .  0  12 

User  groups .  2  41 

Personal  computing  library .  0  29 

Equipment  demonstration  facilities .  2  38 


Figure  8.  Trends  in  Personal  Computing 


Based  on  the  degree  of  success  experienced  by  most  ICs , 
even  those  facing  great  internal  resistance,  it  appears  that 
any  organization  that  makes  a  bonafide  effort  at  establish¬ 
ing  an  IC  can  be  successful.  Nevertheless,  some  organiza¬ 
tions,  unaware  of  how  desperately  they  are  in  need  of  an  IC, 
are  reluctant  to  establish  one.  As  one  author  states: 

Many  organizations  are  spending  more  on  user-purchased 
hardware,  software  and  services  than  they  realize.  One 
large  manufacturing  company  discovered  that  end-user  pur¬ 
chases  accounted  for  40%  of  the  total  dollars  spent  on 
hardv;are,  software  and  services.  In  some  instances  these 
dollars  were  well  spent;  in  others,  they  were  redundant  to 
what  was  already  available.  The  Information  Center  should 
adopt  a  strategy  that  fits  smoothly  into  the  way  user 
departments  are  currently  operating.  Users  should  not  be 
forced  to  convert  to  the  Information  Center  service  if  it 
will  impair  their  productivity  or  cost  them  more. 

[Ref.  168:  p.  32] 

These  organizations  are  becoming  aware  of  the  need  to  con¬ 
trol  information  and  information  technology.  One  influence 
on  this  awareness  is  the  Foreign  Corrupt  Practices  Act 
(FCPA)  of  1977  which  requires  managers  to  implement  internal 
controls  on  corporate  assets.  Information,  data,  and  com¬ 
puting  resources  are  being  considered  assets  under  the  FCPA 
and  therefore  should  be  controlled.  Kevin  Francella  shows, 
in  a  more  universal  context,  the  impact  of  information  as  an 
asset : 

As  the  United  States  suffers  the  spasms  of  moving  from  an 
industrial  society  to  an  information  society,  US  business 
is  beginning  to  regard  information  as  a  tangible  asset. 
Information  processing  activities  account  for  about  70 
percent  of  the  US  employment,  and  also  account  for  more 
than  46  percent  of  the  Gross  National  Product,  according 
to  figures  from  the  National  Science  Foundation. 

[Ref . ' 1 69:  p.  15] 
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B.  APPLICATION  OF  THE  METHODOLOGY 


The  SDLC  methodology  is  a  viable  way  to  evaluate  and 
implement  an  IC.  This  thesis  has  given  general  guidance  as 
to  how  to  apply  a  slightly  modified  version  of  the  SDLC  as 
proposed  by  Michael  J.  Powers,  David  R.  Adams,  and  Harlan  D. 
Mills  [Ref.  170].  The  major  SDLC  modifications  were  those 
that  were  required  to  better  adapt  the  SDLC  to  the  IC  situa¬ 
tion.  This  methodology  can  be  used  as  extensively  or  as 
sparingly  as  the  situation  warrants.  It  also  has  the  flexi¬ 
bility  to  complement  other  methodologies  and  can  be  used  as 
imaginatively  as  necessary.  For  the  manager  who  is  suddenly 
faced  with  the  task  of  establishing  an  IC  and  who  has  no 
idea  as  to  how  to  proceed,  this  thesis  can  be  of  significant 
value.  For  the  manager  with  experience  with  the  SDLC  meth¬ 
odology,  it  should  even  be  easier  to  benefit  from  this 
thesis . 

There  are  other  methodologies  that  can  be  used  to  estab¬ 
lish  an  IC.  One  method,  as  proposed  by  Jean  L.  Chastain,  is 
to  not  use  any  methodology  at  all: 

If  you  want  to  set  up  an  information  center  and  you  don't 
have  a  lot  of  money  to  do  it,  the  best  plan  may  be  not  to 
plan  at  all.  "I'm  challenging  you  to  try  it  even  without 
a  budget,  without  proper  support,"  said  Jean  L.  Chastain, 
information  center  project  manager  at  Economics 
Laboratory,  Inc.,  a  manufacturing  company  based  in  St. 
Paul,  Minn.  "It  doesn't  take  a  lot  of  money.  A  success¬ 
ful  outcome  is  determined  more  by  attitude  than  by  budg¬ 
et,"  she  told  a  recent  conference  here.  [Ref.  171:  p.  22] 

It  would  seem  that  this  only  works  where  the  IC  is  small  and 

not  comprehensive.  Another  method  that  is  highly  successful 
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is  to  utilize  familiar  methodologies.  Wetherbe  covers  this 
topic  well; 

Many  organizations  develop  their  own  formal  systems  devel¬ 
opment  methodology.  Research  indicates  that  these  method¬ 
ologies  seem  to  work  as  well  as  the  formalized  development 
methodologies.  The  important  thing  is  that  a  comprehen¬ 
sive  template  or  checklist  must  be  used  to  manage  the 
process.  One  criticism  of  systems  development  methodolo¬ 
gies  is  that  they  are  often  so  comprehensive  and  require 
so  much  attention  to  details  and  procedures  that  they  can 
get  in  the  way  of  progress  particularly  for  short,  simple 
projects.  Accordingly,  the  steps  and  procedures  within  a 
systems  development  methodology  should  only  be  considered 
as  a  checklist,  and  not  every  step  or  procedure  should 
necessarily  be  executed  for  each  development  project.  In 
other  words,  some  discretion  should  be  used  in  evaluating 
which  items  on  a  checklist  are  appropriate  for  a  particu¬ 
lar  project.  [Ref.  172:  p.  129] 

An  advantage  of  the  systems  approach  is  the  attainment 
of  synergy.  "This  means,  simply,  that  when  a  system  is 
functioning  as  it  should,  it  produces  results  with  a  value 
greater  than  the  total  value  produced  by  its  separate  indi¬ 
vidual  parts."  [Ref.  173:  p.  5]  Another  advantage  of  this 
methodology  is  explained  in  the  following: 

The  value  of  this  hierarchical  approach  lies  in  a  perspec¬ 
tive  that  forces  problem  solvers  and  managers  to  deal  with 
problems  at  different  levels  of  abstraction .  That  is, 
goals  and  objectives  are  formulated  with  increasing  levels 
of  detail  from  top  to  the  bottom  of  the  hierarchy.  At  the 
top  of  the  organization,  goals  are  described  functionally, 
in  terms  of  the  overall  mission.  At  the  bottom  level,  the 
ob^iectives  are  clearly  operationalized  in  terms  of  speci¬ 
fic  actions  that  must  be  taken  or  specific  results  that 
must  occur.  [Ref.  174:  p.  18] 

As  discussed  previously,  the  feasibility  study  is  usual¬ 
ly  a  large  part  of  the  SDLC.  Nevertheless,  it  is  not  a 
mandatory  requirement.  There  are  several  good  reasons  for 
performing  a  feasibility  study.  One  is  that  formal 
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1 usti f ications  for  all  projects  may  be  required  by  the 
organization.  Another  is  to  help  identify  organizational 
priorities.  A  third  reason  is  to  help  identify  objectives 
and  develop  a  standard  against  which  to  measure  success.  On 
the  other  hand,  there  are  also  good  arguments  against  a 
feasibility  study.  Since  the  IC  can  be  considered  a  re¬ 
search  and  development  effort,  it  may  require  little  or  no 
] ustif ication.  Another  reason  may  be  that  the  IC  is  intui¬ 
tively  justifiable  or  the  benefits  are  so  blatantly  abundant 
that  a  feasibility  study  is,  for  all  practical  purposes,  a 
waste  of  resources.  A  final  reason  may  be  because  the  IC  is 
designed  solely  to  solve  a  management  problem  regardless  of 
the  return  on  investment.  Again,  the  circumstances  dictate 
the  action  to  be  taken  but  more  often  than  not,  some  sort  of 
justification  is  required. 

C,  MILITARY  AND  FEDERAL  APPLICATIONS 

Although  this  thesis  has  concentrated  on  ICs  in  the 
private  sector,  this  does  not  have  to  exclude  the  military 
or  federal  agencies.  The  requirement  to  eliminate  fraud 
waste  and  abuse  in  the  federal  government  is  a  good  reason 
to  implement  an  IC.  An  article  from  Government  Computer 
News  [Ref.  175:  p.  26]  lists  two  military  ICs  and  fifteen 
other  federal  ICs  that  have  been  implemented.  This  shows 
that  the  IC  concept  will  work  in  federal  agencies  as  well  as 
the  private  sector. 
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This  does  not  mean,  however,  that  implementing  an  IC  is 
any  easier  in  the  government  than  it  is  in  the  private 
sector.  The  government,  because  of  its  numerous  regulations 
and  bureaucratic  inflexibility,  may  cause  the  application  of 
controls  and  excessive  justification  during  the  first  or 
second  stage  of  technological  assimilation.  This  could 
nullify  the  benefits  to  be  gained  from  an  IC.  Even  worse, 
overregu  lation  could  cause  the  IC  to  fail  before  it  had  a 
chance  to  prove  its  value.  It  seems,  however,  that  those 
agencies  that  have  tried  to  establish  ICs  have  been  success¬ 
ful.  Therefore,  other  federal  agencies  can  learn  not  only 
from  this  group  of  successful  implementors,  but  they  can 
also  learn  from  the  ICs  implemented  in  the  private  sector. 
Therefore,  this  thesis  can  be  of  value  to  the  federal 
manager . 

D.  EPILOGUE 

There  is  general  agreement  that  a  properly  implemented 
IC  is  a  "win-win  situation  for  users  and  DP  (data  processing 
department)  alike."  [Ref.  176:  p.  25]  Although  managers 
are  still  asking  what  an  IC  can  do  for  their  organization, 
these  same  managers  "are  beginning  to  realize  that  the 
benefits  of  information  access  and  analytical  capability 
outweiuh  the  time  taken  to  handle  the  mechanics  of  the 
process."  [ Re£ .  177:  p.  33]  Appendix  A  is  a  combination 

■' f  two  lists  of  IC  benefits:  one  list  is  from  the  FTP 
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31.  Unnecessarily  high  costs  to  the  company  due  to  users 
learning  by  trial  and  error  about  lack  of  compatibility 
with  microcomputer  peripherals. 

32.  Malicious  or  unauthorized  user  behavior  regarding 
company  property. 

NOTE:  The  above  listing  represents  the  concerns  of  52  MIS 
managers  at  a  seminar  on  information  center  management.  The 
list  is  rank  ordered  based  on  the  average  level  of 
importance  from  most  important  (1)  to  least  important  (32). 


Lack  of  integration  of  micro/mainf rame  data  exchange 
and  control . 

Inability  of  mainframe  computing  to  compete  with 
personal  computing  in  terms  of  cost/benefit  in  certain 
areas  . 

Lack  of  control  over  user  computing  resources 
utilization  in  user  departments  by  the  user  department 
management . 

Lack  of  adequate  support  from  hardware  vendors. 

Lack  of  adequate  support  from  software  vendors. 

Lack  of  control  over  user  computing  resources 
utilization  in  user  departments  by  the  MIS  department. 

Personal  computing  is  further  straining  MIS  department 
relations  with  users. 

Lack  of  centralized  management  over  corporate  data 
resources  to  support  user  personal  computing. 

Lack  of  appropriate  staffing  to  identify  and  service 
potential  information  center  customers. 

Lack  of  user  concern  about  personal  computing  equipment 
security . 

Information  overloading  due  to  too  many  vendors  and 
products  in  a  given  area:  micros,  software  packages, 
local  area  networks,  etc. 

Lack  of  user  interest  in  using  personal  computers. 

Lack  of  integration  in  MIS  management  of  personal 
computing  and  mainframe  user  computing. 

Unnecessarily  high  costs  to  the  company  due  to  users 
learning  by  trial  and  error  about  lack  of  compatibility 
with  other  micros. 

Unnecessarily  high  costs  to  the  company  due  to  users 
learning  by  trial  and  error  how  to  negotiate  with 
vendors . 

Measuring  the  level  of  user  computing  activity. 


APPENDIX  C 


MAJOR  PERSONAL  COMPUTING  PROBLEMS 

Lack  of  a  company  plan  for  personal  computing. 

Lack  of  user  education  regarding  a  companywide  and  a 
long-term  perspective  about  personal  computing. 

Unnecessarily  high  costs  to  the  company  due  to  users 
learning  by  trial  and  error  about  lack  of  compatibility 
with  other  micros. 

Poor  maintainability  of  user-developed  systems. 

General  lack  of  communication  between  the  MIS 
department  and  users. 

Overwhelming  growth  of  user  requests  for  assistance 
from  the  MIS  department. 

Unnecessarily  high  costs  to  the  company  due  to  users 
learning  by  trial  and  error  how  to  use  available 
software  packages. 

Contamination  of  corporate  data  on  the  company's 
mainframe . 

Mismatch  of  user  applications  to  other  possible  user 
computing  alternatives,  such  as  mainframe  packages  or 
the  traditional  approach  for  systems  development. 

MIS  department  has  image  problem  with  personal 
computing  users. 

Lack  of  equivalent  or  better  (more  user-friendly,  etc.) 
mainframe  software  packages  to  compete  successfully 
with  microcomputer  software  packages. 

Lack  of  adequate  training  on  products,  computer 
concepts,  etc. 

Unnecessarily  high  costs  to  the  company  due  to  users 
"reinventing  the  wheel"  in  systems  development. 

Lack  of  user  knowledge  or  concern  about  microcomputer 
data  integrity  measures  such  as  a  file  backup. 
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APPENDIX  B 

OBSTACLES  OF  INFORMATION  CENTERS 


FTP  SURVEY  ( 1 983 ) 

CRWTH  SURVEY  (1984) 

1  . 

Inadequate  IS  Resources 

1  . 

Shortage  of  Trainers 

to  Support  IC 

and  Product  Consultants 

2  . 

Resistance  within  IS, 

2. 

Lack  of  End  User  Aware¬ 

Territorial  Conflicts 

ness 

3  . 

Software  Limitations 

3  . 

System  Resource  Shortage 

4  . 

Providing  Access  to  Perti¬ 
nent  Data  Fast  Enough 

4  . 

DP  Resistance 

5. 

Management  Resistance 

5  . 

Lack  of  End-User  Commit¬ 
ment  to  Concept 

6. 

Lack  of  Chargeback 

6  . 

End-User  Reluctance  to 

Train,  Do  the  Work 

7.  Lack  of  Business  Reason,  Cost- Justif ication 

8.  Defining  Criteria  for  Applications  -  IC  vs.  Regular 
Development 

9.  Lack  of  Adequate  Vendor  Support 

10.  Lack  of  Resources  to  Train  End-Users 

1 1 .  Budget  Constraints 

12.  Management's  Attitude 

13.  Other : 

Data  Security 

Selection  of  Initial  End-Users  and  Timeframe 

Restrictions  on  Choice  of  Hardware  and  Software 

Poor  Implementation 

Overlay  High  End-User  Expectations 

Poor  Follow-Through  by  IC  Staff 

Too  Late,  Generation  Language  Already  Implemented 

Growth  in  Utilization 

LacM  of  Charge-Back  Methodology 

Lack  of  Adequate  Standards 


i 

( 


1  1  1 


APPENDIX  A 


BENEFITS  OF  INFORMATION  CENTERS 


FTP  SURVEY  (1983) 


1  .  Increased  End-User  Computer  1  . 

Understanding,  including 
IS  Resource  Utilization, 

Procedures  and  Problems  2. 

2.  Improved  End-User/IS 

Department  Relations  3. 

3.  More  Effective  Utilization 

of  IS  People  Resources  4. 

4.  Improved  End-User 

Productivity  5. 

5.  End-User  More  Self- 
Sufficient,  Independent 

6.  Improved  Decision-Making 
Support 

7.  Ease  of  Access  to  Infor¬ 
mation 

8.  Reduction  in  Applications 
Backlog 

9.  Corporate  Management  Sees 
IS  as  More  Responsive 

0.  Other  Benefits 

Overall  Cost  Reduction 
Better  Definition  of  Business  Needs 
Reduction  of  Outside  Timesharing  Costs 
Increased  Creative  Use  of  Computing 
Better  Resource  Management 
Developing  Training  for  the  Department 
Automation  of  Considerable  Clerical  Tasks 
"Flexible"  Applications 


CRWTH  SURVEY  (1984) 

Increased  Job 
Productivity 

Better  Use  of  Infor¬ 
mation  Resources 

Improved  Computer 
Literacy 

Improved  DP/End  User 
Relations 

Reduction  of  DP 
Backlog 


The  future  of  ICs 


secure  for  the  moment.  They 

have  dchie\’ed  momenturr:  and  are  propagating  rather  rapidly. 

Some  people  are  saying  that  ICs  are,  at  best,  only  temporary 

institutic  s  as  stated  in  the  following: 

An  information  center  is  not  a  permanent  i nsti tut  ion .  . .  . An 
1C  IS  a  limited,  short-term  concept  that  is  a  stepping- 
stone  on  the  road  to  what  one  IC  specialist,  Bernard 
Plagman,  calls  "end-user  computing ....  We  won't  need  the 
information  center  when  natural  language  processing  be¬ 
comes  the  front  end  of  computers,  and  when  the  so-called 
'expert  systems'  become  bus  mess -or  rented  instead  of  DP- 
oriented  as  they  are  today."  (Ref.  183:  p.  45] 

This  view  of  the  future  of  ICs  ignores  the  management  gap 
that  the  IC  concept  fills.  Unless  there  is  a  drastic  re¬ 
structuring  of  organizations,  most  organizations  will  still 
need  some  form  of  centralized  control  and  expertise  for  end 
user  computing.  The  only  lingering  question  is  whether 
ultimately  the  IC  tools  will  eventually  be  treated  as  casu¬ 
ally  as  the  telephone  is  today,  or  whether  there  will  always 
be  a  need  for  the  IC.  It  is  this  author's  opinion  that  the 
IC  IS  more  permanent  than  it  is  temporary. 
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survey  [Ref.  178:  p.  36)  and  the  other  list  is  from  from  The 
Crwth  Information  Center  Survey  [Ref.  179:  p.  17].  These 
lists  are  intended  as  examples  of  reasons  for  an  organiza¬ 
tion  to  establish  an  IC.  These  two  lists  should  not  be 
compared  against  each  other  because  the  sample  sizes,  the 
questions,  and  the  responses  were  different  for  each  study. 
The  only  comparison  intended,  is  to  provide  the  opportunity 
to  note  benefits  that  show  up  on  both  lists  and  which  can 
therefore  be  considered  to  more  accurately  reflect  the  more 
important,  or  at  least  the  most  notable,  benefits. 

Because  benefits  of  ICs  have  been  identified,  it  seems 
appropriate  to  identify  the  obstacles  that  were  listed  by 
the  same  two  previous  surveys,  the  FTP  survey  [Ref.  180: 
p.  37]  and  The  Crwth  Information  Center  Survey  [Ref.  181: 
p.  18].  The  list  of  obstacles  may  help  the  developer  of  an 
IC  as  much,  if  not  more,  than  the  list  of  benefits.  The 
same  comparison  criteria  applies  to  obstacles  as  applied  to 
benefits . 

Prioritizing  can  be  a  problem  for  managers.  IC  priori¬ 
ties  are  sometimes  difficult  to  verbalize,  let  alone  rank. 
Therefore,  Appendix  C  [Ref.  182:  p.  128]  has  been  provided 
to  show  the  major  personal  computing  problems  listed  in 
order  of  importance  as  ranked  by  52  MIS  managers  attending  a 
seminar  on  IC  management.  This  List  can  also  be  used  by  the 
IC  developer  as  a  checklist. 
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